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

Добрый день, Дмитрий.

Из описания схемы:

1. Запись о существовании объекта создается в таблице объектов - тут же
>    и создаются уникальные идентификаторы для всех объектов в системе
> (PRIMARY
>    KEY id).
>    2. Все таблицы значения имеют поля с идентификатором объекта, которому
>    это значение принадлежит.
>    3. Поля и типы объектов описываются в специальных таблицах для типа и
>    ключа соответственно. - это аналоги классов?

Не совсем ясно как вы определяете родственные сущности со схожими наборами свойств при групповой обработке и анализе значений свойств или поиске по ним. 

Каким образом реализованы потребности в группировке объектов по категориям предметной области? Возможно ли иерархическое представление данных в вашей реализации.

Логическое связывание объектов в рамках описываемой предметной области. Формирование структуры контейнеров для объектов в рамках описываемой предметной области?

Априори Ваш подход подразумевает реализацию части базовой логики предметной области средствами СУБД. 

ЗЫ:

На этой неделе я достаточно начитался мнений о том что СУБД это просто ведро с гайками и бизнес логику лучше делать где то там, если сообщение упадет в рассылку не хочу холиварить на эту тему.

вт, 22 июн. 2021 г. в 23:32, Dmitriy Resnyanskiy <zubosem@gmail.com>:

Дмитрий, добрый день.

Простите за задержку с ответом. Забегался, никак до компьютера не доползу с выходных )

Я в самом первом письме скидывал деплой схемы - это пока все, что у нас есть.

Сейчас мы внедряем сразу в два собственных проекта. Внедрение покажет результаты удобства использования.

вс, 20 июн. 2021 г. в 05:46, Дмитрий Иванов <firstdismay@gmail.com>:

Доброго дня, Дмитрий.

Какова степень готовности вашего решения?

Вы уже что то сделали или только в процессе?

По поводу скептических замечаний хочу сказать что они всегда будут. Утверждение что обобщение каким то образом отрицает использование реляционных возможностей СУБД вообще ничем не подкреплено. Вот использование JSON как раз таки дает бесполезную в плане поиска и навигации гибкость. Я рассматривал данный вариант для доступа к иерархическим данным свойств одним запросом, но в итоге ушел в сторону массивов композитных типов, разделив представления объектов на обобщенные (только формализованные данные) и расширенные. Поиск по свойствам при этом работает почти так же быстро как по формализованным данным основной таблицы объектов. 

Самое главное что бы, не грузить народ деталями реализации обобщенного хранилища мы реализовали графический интерфейс для организации системы хранения в рамках произвольной предметной области. Если вы только начали не хотелось бы "ставить на рельсы".

ср, 16 июн. 2021 г. в 01:48, Dmitriy Resnyanskiy <zubosem@gmail.com>:

Игорь, приветствую.

1. Насколько мне известно (я про JSONB), GIN не работает для выборки по порядку (ORDER BY). Поэтому для сортировочных свойств нам придется создавать отдельные индексы B-Tree на каждое требуемое поле дополнительно к GIN.
2. Также JSON-массивы - это не тоже самое, что обычные массивы. И я не смогу использовать шикарные операторы работы с нативными массивами в работе с массивами JSONB.
3. Я захочу использовать GIST индекс для работы с геометрией и я тоже не смогу его использовать в рамках JSONB.
4. А еще полнотекстовый поиск вспомнился ;)

вт, 15 июн. 2021 г. в 22:09, Дмитрий Иванов <firstdismay@gmail.com>:

Конечным носителем данных в нашей реализации является объект (жестко формализованная начальная сущность). Вставка объектов действительно занимает время, но в основном это проверка доступности действия сам объект это одна запись общей таблицы объектов, каждое значение свойства объекта это отдельная запись таблицы значений свойств объектов. Массовые вставки сотен тысяч объектов мы не производили так как не было такой потребности в прикладных задачах, но думаю да это один из минусов. Вообще мы позиционировали свой движок на малые и средние реализации. Однако незначительное число web-разработчиков испытывающих наше решение признали что мы быстрее привычных для них реализаций. 

вт, 15 июн. 2021 г. в 20:15, Dmitriy Resnyanskiy <zubosem@gmail.com>:

Добрый день.

Спасибо что ознакомились. Постгрес действительно разительно отличается от мускула возможностями. Как мне кажется, такое решение мы не смогли бы реализовать на мускуле. Исходили из того, что всегда хочется реляционных возможностей и гибкости в расширении таблиц.

Но в том числе ваш ответ дает нам понять, что это не дичь. Мы попробовали эту структуру на Фиасе, получилось очень быстро. Вставлялся неделю правда )

Еще минус, конечно, трёхэтажные некрасивые селекты, но "дотянуться" можно быстро до любого значения. Ну и конечно агрегация всегда слабая в таких БД. Поэтому хотим использовать кликхаус для возможностей агрегации с подключением данной структуры как справочника.

Готов сверять часы, так сказать, обмениваться мнениями.

Спасибо за ваш ответ.

вт, 15 июн. 2021 г., 17:28 Дмитрий Иванов <firstdismay@gmail.com>:

Добрый день, Дмитрий.

Как Дмитрий Дмитрию скажу что Ваш подход вполне жизнеспособен. Над предложенным Вами вариантом я работаю с 2012 года

использование фиксированных проприетарно индексированных таблиц для хранения расширенных свойств сущностей с заведомо

неизвестной структурой имеет ряд своих недостатков, однако переход на PostgreSQL вдохнул новую жизнь в наше первое решение 

мы реализовали многоуровневое наследование, библиотеку файловых документов с использованием интерфейса БД (без больших объектов при этом) 

и много чего еще интересного, на мой взгляд плюсы перевешивают минусы.

Раз вы пришли независимо к такому решению возможно было бы интересно обменяться соображениями.

API первой версии у нас реализовано на порядка 947 процедурах и работает под MS SQL с использованием файлового сервера. 

Новое решение еще в разработке порядка 671 функции.

---------- Forwarded message ---------
От: Михаил <m.nasedkin@gmail.com>
Date: вт, 15 июн. 2021 г. в 09:35
Subject: Re: Особый способ хранения в базах Postgres
To: Dmitriy Resnyanskiy <zubosem@gmail.com>
Cc: <pgsql-ru-general@lists.postgresql.org>

Я тоже такими вещами занимался, когда по молодости кровь кипела, а
проектов толком не было. Вариаций на данную тему миллион. Вашу работу
одобряю. Мало кто захочет ее применять, потому что, например, я сейчас
в около средней конторе, где бэк-программисты вообще не видят чистого
скуля, с БД оперируют модельные обертки. А мне приходится смотреть на
это в тоске и печали.

Благ и удачи.

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


--
---
С уважением,
Михаил Наседкин