Re: Особый способ хранения в базах Postgres
От | Михаил |
---|---|
Тема | Re: Особый способ хранения в базах Postgres |
Дата | |
Msg-id | CALSKcLQVWbS_HTWPm7=8Z4_y7hyev=YmtW3cYd7pN+p-QVD_QA@mail.gmail.com обсуждение исходный текст |
Ответ на | Особый способ хранения в базах Postgres (Dmitriy Resnyanskiy <zubosem@gmail.com>) |
Ответы |
Re: Особый способ хранения в базах Postgres
|
Список | pgsql-ru-general |
Я тоже такими вещами занимался, когда по молодости кровь кипела, а проектов толком не было. Вариаций на данную тему миллион. Вашу работу одобряю. Мало кто захочет ее применять, потому что, например, я сейчас в около средней конторе, где бэк-программисты вообще не видят чистого скуля, с БД оперируют модельные обертки. А мне приходится смотреть на это в тоске и печали. Благ и удачи. 27.05.2021, Dmitriy Resnyanskiy<zubosem@gmail.com> написал(а): > Всем привет! > > Меня зовут Дмитрий, я решился написать сюда, надеюсь, что попал правильно. > При проектировании БД нередко сталкиваешься с проблемами хранения: > > 1. Хранение и расширение каких-нибудь профайлов чревато альтерами (ALTER > TABLE) в разрастающихся таблицах. > 2. Непонятно, как изящно связывать части профайлов, объектов, как > собирать и прочее. > 3. Возникают сложности с индексацией, потому что хочется искать по всем > полям, а индексы на всю таблицу не повесишь, ну или это создаст другие > проблемы. > 4. Всегда хочется единый идентификатор для всей номенклатуры объектов в > базе данных, чтобы, например, в Кликхаус поставить на него ссылку и > легко > забирать исчерпывающие данные из внешнего словаря. > > Использовать обычную реляционную схему проектирования проблематично по > каждому указанному пункту. Поэтому у нас появилась идея разбить поля по > отдельным таблицам (таблицам значений), в которых поле значения > индексировано. > > 1. Запись о существовании объекта создается в таблице объектов - тут же > и создаются уникальные идентификаторы для всех объектов в системе > (PRIMARY > KEY id). > 2. Все таблицы значения имеют поля с идентификатором объекта, которому > это значение принадлежит. > 3. Поля и типы объектов описываются в специальных таблицах для типа и > ключа соответственно. > 4. Специальные триггеры при вставке записи в таблицы типа и ключа > создают новую уникальную таблицу в системе, где будут храниться значения > объектов. > 5. В системе созданы функции, которые собирают объекты и сохраняют, > распределяя данные по таблицам значений. > 6. Для контроля целостности данных из нескольких полей создаются > специальные таблицы с составными индексами, которые вместе со > специальными > триггерами позволяют правильно записывать и контролировать уникальные > поля > объектов. > 7. Трехэтажными джоинами по индексированным полям можно быстро > "дотянуться" до любых данных объекта. > > Нам очень интересно ваше мнение о проделанной работе. Пожалуйста, взгляните > на нее экспертным взглядом и укажите на проблемы и недостатки такого > подхода. > Возможно, уже давно есть технологии, фреймворки, которые отталкиваются от > тех же задач и проблем, пожалуйста, дайте ссылки на них почитать. > Код не претендует на совершенство и, скорее всего, стоит надеть специальный > костюм ассенизатора, прежде чем туда заглянуть ;) > Не судите строго, большое спасибо. > -- --- С уважением, Михаил Наседкин
В списке pgsql-ru-general по дате отправления:
Предыдущее
От: Sergei KornilovДата:
Сообщение: Re: PostgreSQL 12-1C проведение документов в ~3 раза медленнее на Linux