Re: PostgreSQL vs ...
- From
- Tolik Tentser (2:5000/292.17)
- To
- Vladimir Pavlikov (2:5054/37.63)
- Date
- 2005-01-28T22:05:10Z
- Area
- SU.DBMS
Hi, Vladimir!
В чреве акулы, пойманной 27 Jan 05 05:19:56,
дети капитана Гранта нашли письмо на тему 'Re: PostgreSQL vs ...':
TT>> Будем на каждое состояние заводить по таблице?
TT>> Или шаманить с набиением дополнительной таблицы несколькими
TT>> состояниями?
VP> Зачем? Состояния, табой перечисленные - это один атрибут, "состояние".
Следующий шаг - вынести все записи с состоянием в отдельную таблицу
А чем низкоселективные хуже?
TT>> И то и другое явно плохо, особенно, когда набор состояний меняется.
VP> Про "плохо" я уже не раз слышал, осталось понять - чем. Что означает
VP> "набор состояний меняется" - я не понял. Расширяться (детализиро-
VP> ваться) - может, конечно. Чем это плохо, и что из этого следует?
Хорошо, давай с другой стороны.
Предположим, что все они одинаково селективные. Мысли что-то куда-то
выносить ни у кого не появляется. Более того - очевидным образом этот
"вынос" добавит только проблем.
Соответственно - все эти финты - есть не более чем преодоление каких-то
ограничений сервера.
Чем плохо - ну, например, нужен дополнительный код, при изменениях в главной
таблице эту вторую таблицу с состояниями модифицирующий. Плюс - делающий это
только для некоторого набора состояний. А при изменении этого набора - надо
или код менять, или для этого вести еще отдельные флаги "селективных"
состояний. И учить админа с ними работать. Всё это удобства и простоты явно
не добавляет
VP> Собственно, очень желательно (если уж пришла охота об этом
VP> поговорить) рассмотреть мои соображения о двух разных
VP> задачах и утверждение о ненормализованности схемы. Вряд
VP> ли тебе надо рассказывать, чем плоха ненормализованность.
VP> А вопрос простой - есть она или нет. И все.
Вообще не понял, при чем тут в данном вопросе нормализация
VP> With best regards, Vladimir Pavlikov. E-mail: vvp@soil.msu.ru
Bye ...
Tolik Tentser
tolik@katren.ru
ICQ 15925834
--- InterSquish NNTP Server/FTN Gate v.1.7.0.4
* Origin: NNTP point at Nuuzerpogodi station (2:5000/292.17)
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/26 39 72 76 97 111 130 153 166 292 5000 5001/50 211 5001
SEEN-BY: 5002/5002 5003/34 5006/1 5007/1 5009/14 5010/53 70 146 5011/13
SEEN-BY: 5012/23 5015/4 28 5019/5 22 5020/52 104 115 118 128 133 150 175 201
SEEN-BY: 5020/362 371 400 545 639 642 715 755 758 780 794 892 894 902 921 968
SEEN-BY: 5020/982 1057 1100 1169 1200 1212 1234 1523 1604 1626 1642 1826 1835
SEEN-BY: 5020/1873 1922 1930 1992 2020 2200 2238 4400 4441 8383 12000 5022/5
SEEN-BY: 5022/128 5023/11 5025/750 5026/14 45 5029/32 5030/69 115 195 217 382
SEEN-BY: 5030/436 473 556 611 920 966 1016 1900 5031/47 5033/5 21 35 5034/8
SEEN-BY: 5035/10 5036/1 13 5037/21 31 36 5041/4 5042/8 13 5045/7 5049/157
SEEN-BY: 5050/9 41 5051/15 35 5053/16 5054/1 8 9 10 28 35 37 45 50 63 5055/95
SEEN-BY: 5056/16 5057/1 5058/24 77 5059/20 5060/88 5061/15 5062/10 5063/41 51
SEEN-BY: 5064/5 7 35 5066/18 5070/26 66 1222 5071/22 5075/10 5079/49 5080/1003
SEEN-BY: 5081/2 5082/6 5083/13 21 5084/32 5093/4 27 5095/1 20 5100/113 6001/3
SEEN-BY: 6009/1 6023/1 6033/2727 6045/7
PATH: 5000/292 111 76 5020/400 4441 52 5054/1 37