Re: PostgreSQL vs ...

From

Michael (2:5020/400)

To

Tolik Tentser (2:5054/37.63)

Date

2005-03-23T08:19:16Z

Area

SU.DBMS

From: "Michael" <michael@rusmedia.dk>

Fri Jan 28 2005 22:05, Tolik Tentser wrote to Vladimir Pavlikov:

Наверняка это уже не актуально и каждый остался при своем, но в этом треде, с
моей точки зрения конечно, Павликов абсолютно прав. 
 

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

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

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

 TT>>> И то и другое явно плохо, особенно, когда набор состояний меняется.

 VP>> Про "плохо" я уже не раз слышал, осталось понять - чем. Что означает
 VP>> "набор состояний меняется" - я не понял. Расширяться (детализиро- 
 VP>> ваться) - может, конечно. Чем это плохо, и что из этого следует?

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


Вопрос в том, для чего выбираются документы. Как правило по таким атрибутам
как состояние либо делается некая агрегация или массовая обработка документов.
Для агрегации, скорее всего, основная таблица не нужна и агрегация будет
работать быстро. Второй вариант похож на некую сервесную операцию, типа
бэкапа, что не критично для повседневной работы пользователя.  

Если по атрибуту состояния документы выбираются для редактирования - таких
документов принципиально не может быть много. С ними идет текущая работа и
мешать их с историческими данными было бы ошибкой просто из тех соображений,
что объем исторических данных, как правило, значительно превышает объем
текущих документов. 

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

На самом деле, абсолютно все что связано с созданием модели данных - это не
более чем финты для преодоления каких-то ограничений сервера. Если бы этого не
нужно было делать, вполне можно было бы создать одну, world wide, таблицу (или
нечно многомерное) и ни о чем не думать.

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

Где бы и как бы состояние не хранилось - нужен код для учета изменений.

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


С практической точки зрения - часто ли меняется онажды заведенный и
устоявшийся набор состояний?


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

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

Небольшой набор данных может быть денормализован, большой набор данных должен
быть нормализован. Собственно в этом и заключается противоречивость способов
хранения исторических и текущих данных и необходимость их разделения.

BR
Michael

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

PATH: 5020/400 4441 52 5054/1 37