From: | Dmitriy Resnyanskiy <zubosem(at)gmail(dot)com> |
---|---|
To: | pgsql-ru-general(at)lists(dot)postgresql(dot)org |
Subject: | Особый способ хранения в базах Postgres |
Date: | 2021-05-26 23:55:43 |
Message-ID: | CAHAqJ9KL5u9mk5nRzLziTGg0pCbd78EndHa=gnjdaS05dOwXGQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-ru-general |
Всем привет!
Меня зовут Дмитрий, я решился написать сюда, надеюсь, что попал правильно.
При проектировании БД нередко сталкиваешься с проблемами хранения:
1. Хранение и расширение каких-нибудь профайлов чревато альтерами (ALTER
TABLE) в разрастающихся таблицах.
2. Непонятно, как изящно связывать части профайлов, объектов, как
собирать и прочее.
3. Возникают сложности с индексацией, потому что хочется искать по всем
полям, а индексы на всю таблицу не повесишь, ну или это создаст другие
проблемы.
4. Всегда хочется единый идентификатор для всей номенклатуры объектов в
базе данных, чтобы, например, в Кликхаус поставить на него ссылку и легко
забирать исчерпывающие данные из внешнего словаря.
Использовать обычную реляционную схему проектирования проблематично по
каждому указанному пункту. Поэтому у нас появилась идея разбить поля по
отдельным таблицам (таблицам значений), в которых поле значения
индексировано.
1. Запись о существовании объекта создается в таблице объектов - тут же
и создаются уникальные идентификаторы для всех объектов в системе (PRIMARY
KEY id).
2. Все таблицы значения имеют поля с идентификатором объекта, которому
это значение принадлежит.
3. Поля и типы объектов описываются в специальных таблицах для типа и
ключа соответственно.
4. Специальные триггеры при вставке записи в таблицы типа и ключа
создают новую уникальную таблицу в системе, где будут храниться значения
объектов.
5. В системе созданы функции, которые собирают объекты и сохраняют,
распределяя данные по таблицам значений.
6. Для контроля целостности данных из нескольких полей создаются
специальные таблицы с составными индексами, которые вместе со специальными
триггерами позволяют правильно записывать и контролировать уникальные поля
объектов.
7. Трехэтажными джоинами по индексированным полям можно быстро
"дотянуться" до любых данных объекта.
Нам очень интересно ваше мнение о проделанной работе. Пожалуйста, взгляните
на нее экспертным взглядом и укажите на проблемы и недостатки такого
подхода.
Возможно, уже давно есть технологии, фреймворки, которые отталкиваются от
тех же задач и проблем, пожалуйста, дайте ссылки на них почитать.
Код не претендует на совершенство и, скорее всего, стоит надеть специальный
костюм ассенизатора, прежде чем туда заглянуть ;)
Не судите строго, большое спасибо.
Attachment | Content-Type | Size |
---|---|---|
202003181818_nerd_structure.sql | application/octet-stream | 77.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Taras Savchuk | 2021-06-04 12:01:43 | PostgreSQL 12-1C проведение документов в ~3 раза медленнее на Linux |
Previous Message | Aleksey M Boltenkov | 2020-08-20 13:36:53 | RE: UPDATE WHERE SELECT по париционированным таблицам |