Re: Особый способ хранения в базах Postgres

Спасибо всем вам за ваши ответы. Приятно слышать, что мы не совсем дичь
сделали :) Мы проверяли эту структуру на Фиасе, работает очень шустро.
Правда, очевидно, что этому предшествовала недельная загрузка данных. Хотя
нас это по-моему не пугает.
Хочется, конечно, услышать от вас гипотетические проблемы, которые могут
возникнуть от такого размещения данных, ну кроме увеличенного времени
вставки объектов. Я, к примеру, знаю, что постгрес открывает на каждую
существующую таблицу и индексы файловый дескриптор. А в операционных
системах, насколько мне известно, их количество ограничено. И еще хотелось
бы узнать, почему постгрес "проседает", если сортировать ORDER BY по
нескольким индексированным свойствам разных таблиц одновременно? Хотелось
бы узнать техническую причину такого поведения. Я себе представляю, что для
такой сортировки постгрессом создаётся временная таблица, я правильно мыслю?
Спасибо.

вт, 15 июн. 2021 г., 8:35 Михаил <m(dot)nasedkin(at)gmail(dot)com>:

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