Re: PostgreSQL vs ...

From

Vladimir Pavlikov (2:5020/400)

To

Tolik Tentser (2:5054/37.63)

Date

2005-01-29T03:58:16Z

Area

SU.DBMS

From: "Vladimir Pavlikov" <vvp@soil.msu.ru>

Hello, Tolik!
You wrote to Vladimir Pavlikov on Fri, 28 Jan 2005 22:05:11 +0300:

TT>>> Будем на каждое состояние заводить по таблице?

VP>> Зачем? Состояния, табой перечисленные - это один атрибут, "состояние".

TT> Следующий шаг - вынести все записи с состоянием в отдельную таблицу
TT> А чем низкоселективные хуже?

У меня deja vu - помнишь наши бодания о контроле вводимых данных
на клиенте/сервере? Я утверждал, что ошибки нужно править раньше,
по мере их обнаружения. А ты - что сервер и так их завернет.
Тут, в сущности, то же самое. Я утверждаю, что речь идет о разных
сущностях. Более того - принадлежащих разным задачам. Т.е это
д.б. _две_ таблицы изначально. И только потом, при желании,
можно "сэкономить" на числе таблиц (потеряв в масштабировании
схемы, как минимум).
Ты исходишь из "как попроще" сразу. Отсуда у тебя и "следующий
шаг". Мой подход лучше по нескольким параметрам, но сейчас
речь не об этом. Я просто задал вопрос, и хотел бы получить на
него ответ. Но - ниже.
ЗЫ. Повторяю в стотридцатьсельмой раз - "низкоселективность",
сам факт наличия индексов и прочую требуху я не рассматриваю!
Речь только о адекватности схемы заявленной задаче!!!

TT> Хорошо, давай с другой стороны.
TT> Предположим, что все они одинаково селективные. Мысли что-то куда-то
TT> выносить ни у кого не появляется. Более того - очевидным образом этот
TT> "вынос" добавит только проблем.

Толик, это не с другой. 138-ой и последний - ПОЯВИЛАСЬ!  У меня. Потому
что. Без селективности и индексов. Ибо до них еще не дошли - застряли (вы,
не я) много раньше.

TT> Соответственно - все эти финты - есть не более чем преодоление каких-то
TT> ограничений сервера.

Еще раз увижу этот бред - за политкорректность не ручаюсь. Ну хочешь
оспорить _мою_ мысль - прочти ее! Она изложена уже много раз и
разжевана до неприличия. Я тоже торможу, бывает, но есть же
какие-то границы? :(

TT> Чем плохо - ну, например, нужен дополнительный код, при изменениях в
TT> главной таблице эту вторую таблицу с состояниями модифицирующий. Плюс -
TT> делающий это только для некоторого набора состояний. А при изменении
TT> этого набора - надо или код менять, или для этого вести еще отдельные
TT> флаги "селективных" состояний. И учить админа с ними работать. Всё это
TT> удобства и простоты явно не добавляет

СП, состоящее не из одного апдейта, а двух. Что до кода - он должен
быть адекватным задаче. А не "как можно проще несмотря на...".
При изменении набора код менять придется _всегда_ - это изменение
условий задачи и, соответственно, диаграммы переходов. Пойми,
чудак-человек - я не агитирую за обязательность двух таблиц!
Хочешь одну (если проблем не порождает) - делай. Потерю масшта-
бирования я уже демонстрировал (на то письмо - ни одного отклика
почему-то). Не нужна масштабируемость? - нет проблем. Я ратую не
за конкретную реализацию, а за полноту анализа.

VP>> Собственно, очень желательно (если уж пришла охота об этом
VP>> поговорить) рассмотреть мои соображения о двух разных
VP>> задачах и утверждение о ненормализованности схемы. Вряд
VP>> ли тебе надо рассказывать, чем плоха ненормализованность.
VP>> А вопрос простой - есть она или нет. И все.

TT> Вообще не понял, при чем тут в данном вопросе нормализация

"Не понял - переспроси!" (С) я:) Не, ну в самом деле - я про Фому,
а "отвечают" про Ерему :(
1. Построение инфологической схемы начинается с анализа на
    задачи, сущности и связи. Под каждую сущность (в частности)
    отводится _своя_ таблица.
2. Появившаяся в результате схема подвергается нормализации,
    т.е. "проверке на вшивость".
3. Предложенная схема _мой_ анализ (нормализацию) не прошла.

"Документ" - сущность в задаче "Информационное хранилище" -
внесение, хранение, редактирование, селектирование, публикация
и пр. "Стадия подготовки" - сущность в другой задаче, "Документо-
оборот". Т.е. две разные сущности даже не в одной задаче, а в двух
разных. В одной таблице...
Рассмотри тему в _предложенных_ рамках. Сделай заключение,
и лишь потом смотри на "удобства". Можешь сделать любой
вывод - в рамках темы ни словом не возражу. Не хочешь? -
в смысле "в предложенных"? Как хочешь, но не со мной. По
крайней мере - не в этой ветке.

With best regards, Vladimir Pavlikov.  E-mail: vvp@soil.msu.ru



-- 
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5.3
 * Origin: Talk.Mail.Ru (2:5020/400)
SEEN-BY: 50/203 520 450/159 186 451/30 452/25 100 454/9 455/15 461/33 43 74
SEEN-BY: 461/106 132 640 463/92 464/34 465/213 469/125 999 478/44 550/5068
SEEN-BY: 4614/20 4616/3 4625/8 9 4627/10 4635/4 1024 4651/25 4653/10 4657/50
SEEN-BY: 5000/76 5000 5001/50 211 5001 5002/5002 5003/34 5006/1 5007/1 5009/14
SEEN-BY: 5010/53 70 146 5011/13 5012/23 5015/4 28 5019/5 22 5020/52 104 115
SEEN-BY: 5020/118 128 133 150 175 201 362 371 400 545 639 642 715 755 758 780
SEEN-BY: 5020/794 892 894 902 921 968 982 1057 1100 1169 1200 1212 1234 1523
SEEN-BY: 5020/1604 1626 1642 1826 1835 1873 1922 1930 1992 2020 2200 2238 4400
SEEN-BY: 5020/4441 8383 12000 5022/5 128 5023/11 5025/750 5026/14 45 5029/32
SEEN-BY: 5030/69 115 195 217 382 436 473 556 611 920 966 1016 1900 5031/47
SEEN-BY: 5033/5 21 35 5034/8 5035/10 5036/1 13 5037/21 31 36 5041/4 5042/8 13
SEEN-BY: 5045/7 5049/157 5050/9 41 5051/15 35 5053/16 5054/1 8 9 10 28 35 37
SEEN-BY: 5054/45 50 63 5055/95 5056/16 5057/1 5058/24 77 5059/20 5060/88
SEEN-BY: 5061/15 5062/10 5063/41 51 5064/5 7 35 5066/18 5070/26 66 1222
SEEN-BY: 5071/22 5075/10 5079/49 5080/1003 5081/2 5082/6 5083/13 21 5084/32
SEEN-BY: 5093/4 27 5095/1 20 5100/113 6001/3 6009/1 6023/1 6033/2727 6045/7

PATH: 5020/400 4441 52 5054/1 37