DI> В данном случае сущность - это измерение.
ну эта сущность тоже хранится в виде одного элемента hstore.
а если уж буквоедствовать, то сущность - элемент внутри hstore, только
мы же все равно пользуемся им там где он удобнее? ;)
DI> Лично я вообще бы не стал задумываться над тем, сколько строк будет
DI> содержать таблица, потому что таких ограничений PostgreSQL не накладывает
DI> (есть лимит размера таблицы - 32 ТБ).
а в случае сбоя диска (например) восстановление таблицы 5 млн строк vs
восстановление таблицы 500 тыс строк насколько отличается?
в MySql при таблицах одинакового размера (в смысле в мегабайтах)
таблица содержащая больше строк банально дольше восстанавливается
после сбоя. а так же заливка дампа итп тоже дольше.
на цифрах ~5 млн времена необходимые на ликвидацию последствий сбоя
начинают измеряться часами.
понятно что сбои - нештатная ситуация, но всякое бывает, бывает что
хостер и электричество рубит...
DI> Хранение данных в таблице в
DI> классическом виде, где каждая строка представляет отдельную сущность,
DI> предоставляет всю мощь реляционных БД, поэтому, на мой взгляд,
DI> является предпочтительным всегда.
ну тогда и hstore предпочтительно хранить в таблице |name|value|
или даже |name_id|value| только это уже будет перебор :)
DI> Но видимо Вы не один, кого заботит этот вопрос (и на то есть, конечно,
DI> причины).
DI> Поэтому PostgreSQL явно поддерживает разделение таблиц на несколько.
DI> Подробности здесь -
DI> http://www.postgresql.org/docs/9.0/static/ddl-partitioning.html
да я это читал, планирую применить это в перспективе.
как я понимаю в любой момент любую таблицу можно сделать родительской
для другой и перенести часть данных в эту другую таблицу :)
DI> PS. Я не настаиваю на том, что моё мнение является единственным правильным,
DI> ибо вера в единственно правильное решение является детской болезнью (хотя
DI> этим часто страдают и взрослые) :-)
DI> И поэтому в любом случае проектное решение остаётся только за Вами.
Я очень Вам благодарен за те советы что Вы мне дали (и надеюсь будете
продолжать давать). Я пока только осваиваю Pg и постоянно наталкиваюсь
на то что мой имеющийся опыт тут либо вреден либо не нужен :)
DI> PPS. В PostgreSQL нет функции сотрировки массивов с использованием
DI> оператора упорядочивания, определяемого пользователем.
ну можно всегда сделать unnest -> order by -> array_agg на самом деле
:)
--
. ''`. Dmitry E. Oboukhov
: :’ : email: unera@debian.org jabber://UNera@uvw.ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
