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

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

>
> DI> Какой смысл использовать массив, когда можно просто
> DI> добавлять данные в таблицу в хронологическом порядке?
> DI> Причём хронологию будет фиксировать сама СУБД (очень просто
> DI> достижимо использованием now() в качестве значения по умолчанию).
>
> ну смысл простой:
> 1. данные преимущественно выбираются только скопом (очень редко из
> скопа делается срез, но тут можно сделать unnest), на уровне тех
> скопов которыми они выбираются они и группируются в массивы.
> то есть по сути массив измерений - одна сущность :)
>
В данном случае сущность - это измерение.
То, сколько за один раз снимается измерений, не является существенной
деталью проекта. А то, как множество измерений хранится в БД -
вообще является деталью реализации.

> 2. выбор таблица на 500 тыс строк vs таблица на 5-50 млн строк, при том
> что индексы нафиг там не нужны (включая PRIMARY KEY) пихает прямо в
> направлении использования массива в столбике :). а когда там станет 5
> млн строк, то распакованная таблица будет 50-500 млн. 5 млн это еще
> тот размер который в случае чего быстро (относительно)
> восстанавливается после сбоев (я правда со сбоями на постгрисе не
> работал, а на mysql мы от этого порога начинали таблицы дробить на
> более мелкие)
>
Лично я вообще бы не стал задумываться над тем, сколько строк будет
содержать таблица, потому что таких ограничений PostgreSQL не накладывает
(есть лимит размера таблицы - 32 ТБ). Хранение данных в таблице в
классическом виде, где каждая строка представляет отдельную сущность,
предоставляет всю мощь реляционных БД, поэтому, на мой взгляд,
является предпочтительным всегда.
Но видимо Вы не один, кого заботит этот вопрос (и на то есть, конечно,
причины).
Поэтому PostgreSQL явно поддерживает разделение таблиц на несколько.
Подробности здесь -
http://www.postgresql.org/docs/9.0/static/ddl-partitioning.html

PS. Я не настаиваю на том, что моё мнение является единственным правильным,
ибо вера в единственно правильное решение является детской болезнью (хотя
этим часто страдают и взрослые) :-)
И поэтому в любом случае проектное решение остаётся только за Вами.

PPS. В PostgreSQL нет функции сотрировки массивов с использованием
оператора упорядочивания, определяемого пользователем.

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