From: | "Dmitry E(dot) Oboukhov" <unera(at)debian(dot)org> |
---|---|
To: | Dmitriy Igrishin <dmitigr(at)gmail(dot)com> |
Cc: | pgsql-ru-general(at)postgresql(dot)org |
Subject: | Re: Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы |
Date: | 2011-03-11 13:03:57 |
Message-ID: | 20110311130356.GB8174@apache.rbscorp.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-ru-general |
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(at)debian(dot)org jabber://UNera(at)uvw(dot)ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey N. Oktyabrski | 2011-03-11 13:45:50 | Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы |
Previous Message | Dmitriy Igrishin | 2011-03-11 12:16:18 | Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы |