Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы
| От | Dmitriy Igrishin |
|---|---|
| Тема | Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы |
| Дата | |
| Msg-id | AANLkTi=z6q-EUfqY7MXWHvf9dpT+QbM-_AHsSwNpgBgz@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [pgsql-ru-general] hstore & plperl & массивы (Dmitriy Igrishin <dmitigr@gmail.com>) |
| Ответы |
Re: Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы
("Dmitry E. Oboukhov" <unera@debian.org>)
|
| Список | pgsql-ru-general |
11 марта 2011 г. 16:03 пользователь Dmitry E. Oboukhov <unera@debian.org> написал:
DI> В данном случае сущность - это измерение.
ну эта сущность тоже хранится в виде одного элемента hstore.
а если уж буквоедствовать, то сущность - элемент внутри hstore, только
мы же все равно пользуемся им там где он удобнее? ;)
Данные, хранимые в 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.
есть 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}
и того проще, например
dmitigr=> SELECT array_agg(fname ORDER BY id DESC) FROM test;
array_agg
-------------
{ivan,dima}
--
. ''`. 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
--
// Dmitriy.
В списке pgsql-ru-general по дате отправления:
Предыдущее
От: "Andrey N. Oktyabrski"Дата:
Сообщение: Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы
Следующее
От: "Dmitry E. Oboukhov"Дата:
Сообщение: Re: Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы