Re: Особый способ хранения в базах Postgres - Mailing list pgsql-ru-general
From | Dmitriy Resnyanskiy |
---|---|
Subject | Re: Особый способ хранения в базах Postgres |
Date | |
Msg-id | CAHAqJ9JYkTvPbc=tZSPy4sif=mhY0RyrH72uKpHqo5LLWdEYOQ@mail.gmail.com Whole thread Raw |
In response to | Re: Особый способ хранения в базах Postgres (Михаил <m.nasedkin@gmail.com>) |
Responses |
Re: Особый способ хранения в базах Postgres
|
List | pgsql-ru-general |
Спасибо всем вам за ваши ответы. Приятно слышать, что мы не совсем дичь сделали :) Мы проверяли эту структуру на Фиасе, работает очень шустро. Правда, очевидно, что этому предшествовала недельная загрузка данных. Хотя нас это по-моему не пугает.
Хочется, конечно, услышать от вас гипотетические проблемы, которые могут возникнуть от такого размещения данных, ну кроме увеличенного времени вставки объектов. Я, к примеру, знаю, что постгрес открывает на каждую существующую таблицу и индексы файловый дескриптор. А в операционных системах, насколько мне известно, их количество ограничено. И еще хотелось бы узнать, почему постгрес "проседает", если сортировать ORDER BY по нескольким индексированным свойствам разных таблиц одновременно? Хотелось бы узнать техническую причину такого поведения. Я себе представляю, что для такой сортировки постгрессом создаётся временная таблица, я правильно мыслю?
Спасибо.
вт, 15 июн. 2021 г., 8:35 Михаил <m.nasedkin@gmail.com>:
Я тоже такими вещами занимался, когда по молодости кровь кипела, а
проектов толком не было. Вариаций на данную тему миллион. Вашу работу
одобряю. Мало кто захочет ее применять, потому что, например, я сейчас
в около средней конторе, где бэк-программисты вообще не видят чистого
скуля, с БД оперируют модельные обертки. А мне приходится смотреть на
это в тоске и печали.
Благ и удачи.
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 by date: