Особый способ хранения в базах Postgres - Mailing list pgsql-ru-general

From Dmitriy Resnyanskiy
Subject Особый способ хранения в базах Postgres
Date
Msg-id CAHAqJ9KL5u9mk5nRzLziTGg0pCbd78EndHa=gnjdaS05dOwXGQ@mail.gmail.com
Whole thread Raw
Responses Re: Особый способ хранения в базах Postgres  (Михаил <m.nasedkin@gmail.com>)
List pgsql-ru-general
Всем привет!

Меня зовут Дмитрий, я решился написать сюда, надеюсь, что попал правильно.
При проектировании БД нередко сталкиваешься с проблемами хранения:
  1. Хранение и расширение каких-нибудь профайлов чревато альтерами (ALTER TABLE) в разрастающихся таблицах.
  2. Непонятно, как изящно связывать части профайлов, объектов, как собирать и прочее.
  3. Возникают сложности с индексацией, потому что хочется искать по всем полям, а индексы на всю таблицу не повесишь, ну или это создаст другие проблемы.
  4. Всегда хочется единый идентификатор для всей номенклатуры объектов в базе данных, чтобы, например, в Кликхаус поставить на него ссылку и легко забирать исчерпывающие данные из внешнего словаря.
Использовать обычную реляционную схему проектирования проблематично по каждому указанному пункту. Поэтому у нас появилась идея разбить поля по отдельным таблицам (таблицам значений), в которых поле значения индексировано.
  1. Запись о существовании объекта создается в таблице объектов - тут же и создаются уникальные идентификаторы для всех объектов в системе (PRIMARY KEY id).
  2. Все таблицы значения имеют поля с идентификатором объекта, которому это значение принадлежит.
  3. Поля и типы объектов описываются в специальных таблицах для типа и ключа соответственно.
  4. Специальные триггеры при вставке записи в таблицы типа и ключа создают новую уникальную таблицу в системе, где будут храниться значения объектов.
  5. В системе созданы функции, которые собирают объекты и сохраняют, распределяя данные по таблицам значений.
  6. Для контроля целостности данных из нескольких полей создаются специальные таблицы с составными индексами, которые вместе со специальными триггерами позволяют правильно записывать и контролировать уникальные поля объектов.
  7. Трехэтажными джоинами по индексированным полям можно быстро "дотянуться" до любых данных объекта.
Нам очень интересно ваше мнение о проделанной работе. Пожалуйста, взгляните на нее экспертным взглядом и укажите на проблемы и недостатки такого подхода.
Возможно, уже давно есть технологии, фреймворки, которые отталкиваются от тех же задач и проблем, пожалуйста, дайте ссылки на них почитать.
Код не претендует на совершенство и, скорее всего, стоит надеть специальный костюм ассенизатора, прежде чем туда заглянуть ;)
Не судите строго, большое спасибо.
Attachment

pgsql-ru-general by date:

Previous
From: "Aleksey M Boltenkov"
Date:
Subject: RE: UPDATE WHERE SELECT по париционированным таблицам
Next
From: Taras Savchuk
Date:
Subject: PostgreSQL 12-1C проведение документов в ~3 раза медленнее на Linux