AB
Знаю, что не по адресу. Но наверняка тут многие пользуются postgres.
Есть проблема. Хочется хранить вложенные данные рядом. Т.е. не нормализованно по табличкам, а рядом. И искать с индексами.
Есть jsonb, с индексами и json path. НО.
1) jsonb для динамических данных. Тут речь же о данных, имеющих схему и типы.
2) jsonb хранит ключи каждый раз. В итоге по большей части хранятся имена ключей, а не данные.
3) jsonb пока не умеет даты/время. Он точно не будет поддерживать постгресовые типы и индексы. Например диапазоны, гео точки.
Есть подход, применяемый в elastci search, когда данные делают плоскими и хранят каждую колонку как массив.
Еще так делает, например click house.
https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html#nested-arrays-flattening-objects
https://clickhouse.tech/docs/ru/sql-reference/data-types/nested-data-structures/nested/
т.е
Тут есть особенности, если так делать с документом, то будут теряться связи, но если использовать реляции, то все ок.
Таким образом можно встраивать вложенные таблицы.
1) Будут доступны миграции, можно добавить/удалить/изменить колонку
2) Можно строить gin/gist индексы, можно делать фкнциональные индексы
3) Есть схема с привычными типами. Названия полей не пишутся каждый раз.
4) Да, при поиске будет теряться связь между вложенными таблицами, но это такая цена подхода, и если это неприемлемо, то нужно использовать обычные таблички
Кто что думает?
Есть проблема. Хочется хранить вложенные данные рядом. Т.е. не нормализованно по табличкам, а рядом. И искать с индексами.
Есть jsonb, с индексами и json path. НО.
1) jsonb для динамических данных. Тут речь же о данных, имеющих схему и типы.
2) jsonb хранит ключи каждый раз. В итоге по большей части хранятся имена ключей, а не данные.
3) jsonb пока не умеет даты/время. Он точно не будет поддерживать постгресовые типы и индексы. Например диапазоны, гео точки.
Есть подход, применяемый в elastci search, когда данные делают плоскими и хранят каждую колонку как массив.
Еще так делает, например click house.
https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html#nested-arrays-flattening-objects
https://clickhouse.tech/docs/ru/sql-reference/data-types/nested-data-structures/nested/
т.е
post.translation.title string[], post.translation.content text[]. Т.е. данные транспонируют или уплощают.Тут есть особенности, если так делать с документом, то будут теряться связи, но если использовать реляции, то все ок.
Таким образом можно встраивать вложенные таблицы.
1) Будут доступны миграции, можно добавить/удалить/изменить колонку
2) Можно строить gin/gist индексы, можно делать фкнциональные индексы
3) Есть схема с привычными типами. Названия полей не пишутся каждый раз.
4) Да, при поиске будет теряться связь между вложенными таблицами, но это такая цена подхода, и если это неприемлемо, то нужно использовать обычные таблички
Кто что думает?
Я поглядел на проект, который начинался с широких таблиц на протяжении полутора лет. Очень-очень быстро возникли проблемы с дедупликацией данных, да и с разделением их на куски при детализации предметки