Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы

11 марта 2011 г. 16:03 пользователь Dmitry E. Oboukhov
<unera(at)debian(dot)org>написал:

> DI> В данном случае сущность - это измерение.
> ну эта сущность тоже хранится в виде одного элемента hstore.
> а если уж буквоедствовать, то сущность - элемент внутри hstore, только
> мы же все равно пользуемся им там где он удобнее? ;)
>
Данные, хранимые в hstore, - это пары свойств/значений некой сущности,
которые сложно или невозможно предусмотреть на этапе проектирования -
то есть выразить проект через статические типы (в виде таблиц).
То есть hstore позволяет абстрагироваться от свойств, присущих неким
концепциям ("есть концепция и некие её свойства"). При этом, не обязательно
абстрагировать все свойства, такие, как например, время измерения. Для этого
лучше использовать статические типы данных. В результате получится
симбиоз столбцов статических типов данных и столбца(-ов - сомневаюсь)
hstore.

> DI> Лично я вообще бы не стал задумываться над тем, сколько строк будет
> DI> содержать таблица, потому что таких ограничений PostgreSQL не
> накладывает
> DI> (есть лимит размера таблицы - 32 ТБ).
>
> а в случае сбоя диска (например) восстановление таблицы 5 млн строк vs
> восстановление таблицы 500 тыс строк насколько отличается?
>
Зависит от многих факторов, в т.ч. настроек и оборудования. Мой ответ - не
знаю.

> в MySql при таблицах одинакового размера (в смысле в мегабайтах)
> таблица содержащая больше строк банально дольше восстанавливается
> после сбоя. а так же заливка дампа итп тоже дольше.
>
> на цифрах ~5 млн времена необходимые на ликвидацию последствий сбоя
> начинают измеряться часами.
>
> понятно что сбои - нештатная ситуация, но всякое бывает, бывает что
> хостер и электричество рубит...
>
Бывает, конечно, всякое. И по улицам ночью ходить может быть опасно и т.д.
Тем не менее, я считаю, что опасения по поводу восстановления после
сбоев обоснованы, но не должны выходить на передний план при проектировании.

>
> DI> Хранение данных в таблице в
> DI> классическом виде, где каждая строка представляет отдельную сущность,
> DI> предоставляет всю мощь реляционных БД, поэтому, на мой взгляд,
> DI> является предпочтительным всегда.
> ну тогда и hstore предпочтительно хранить в таблице |name|value|
> или даже |name_id|value| только это уже будет перебор :)
>
См. первый комментарий в данном письме касаемо сущностей и что в них
есть hstore.

>
> 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 на самом деле
> :)
>
Начиная с 9.0, аггрегирующие функции поддерживают ORDER BY. Т.о., можно
и того проще, например
dmitigr=> SELECT array_agg(fname ORDER BY id DESC) FROM test;
array_agg
-------------
{ivan,dima}

>
> --
>
> . ''`. 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
>

--
// Dmitriy.