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

Добрый день, Дмитрий.
Из описания схемы:
1. Запись о существовании объекта создается в таблице объектов - тут же
> и создаются уникальные идентификаторы для всех объектов в системе
> (PRIMARY
> KEY id).
> 2. Все таблицы значения имеют поля с идентификатором объекта, которому
> это значение принадлежит.
> 3. Поля и типы объектов описываются в специальных таблицах для типа и
> ключа соответственно. - это аналоги классов?
Не совсем ясно как вы определяете родственные сущности со схожими наборами
свойств при групповой обработке и анализе значений свойств или поиске по
ним.
Каким образом реализованы потребности в группировке объектов по категориям
предметной области? Возможно ли иерархическое представление данных в вашей
реализации.
Логическое связывание объектов в рамках описываемой предметной области.
Формирование структуры контейнеров для объектов в рамках описываемой
предметной области?
Априори Ваш подход подразумевает реализацию части базовой логики предметной
области средствами СУБД.

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

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

> Дмитрий, добрый день.
> Простите за задержку с ответом. Забегался, никак до компьютера не доползу
> с выходных )
> Я в самом первом письме скидывал деплой схемы - это пока все, что у нас
> есть.
> Сейчас мы внедряем сразу в два собственных проекта. Внедрение покажет
> результаты удобства использования.
>
> вс, 20 июн. 2021 г. в 05:46, Дмитрий Иванов <firstdismay(at)gmail(dot)com>:
>
>> Доброго дня, Дмитрий.
>> Какова степень готовности вашего решения?
>> Вы уже что то сделали или только в процессе?
>> По поводу скептических замечаний хочу сказать что они всегда будут.
>> Утверждение что обобщение каким то образом отрицает использование
>> реляционных возможностей СУБД вообще ничем не подкреплено. Вот
>> использование JSON как раз таки дает бесполезную в плане поиска и навигации
>> гибкость. Я рассматривал данный вариант для доступа к иерархическим данным
>> свойств одним запросом, но в итоге ушел в сторону массивов композитных
>> типов, разделив представления объектов на обобщенные (только
>> формализованные данные) и расширенные. Поиск по свойствам при этом работает
>> почти так же быстро как по формализованным данным основной таблицы
>> объектов.
>> Самое главное что бы, не грузить народ деталями реализации обобщенного
>> хранилища мы реализовали графический интерфейс для организации системы
>> хранения в рамках произвольной предметной области. Если вы только начали не
>> хотелось бы "ставить на рельсы".
>>
>> ср, 16 июн. 2021 г. в 01:48, Dmitriy Resnyanskiy <zubosem(at)gmail(dot)com>:
>>
>>> Игорь, приветствую.
>>>
>>> 1. Насколько мне известно (я про JSONB), GIN не работает для выборки
>>> по порядку (ORDER BY). Поэтому для сортировочных свойств нам придется
>>> создавать отдельные индексы B-Tree на каждое требуемое поле дополнительно к
>>> GIN.
>>> 2. Также JSON-массивы - это не тоже самое, что обычные массивы. И я
>>> не смогу использовать шикарные операторы работы с нативными массивами в
>>> работе с массивами JSONB.
>>> 3. Я захочу использовать GIST индекс для работы с геометрией и я
>>> тоже не смогу его использовать в рамках JSONB.
>>> 4. А еще полнотекстовый поиск вспомнился ;)
>>>
>>>
>>> вт, 15 июн. 2021 г. в 22:09, Дмитрий Иванов <firstdismay(at)gmail(dot)com>:
>>>
>>>> Конечным носителем данных в нашей реализации является объект (жестко
>>>> формализованная начальная сущность). Вставка объектов действительно
>>>> занимает время, но в основном это проверка доступности действия сам объект
>>>> это одна запись общей таблицы объектов, каждое значение свойства объекта
>>>> это отдельная запись таблицы значений свойств объектов. Массовые вставки
>>>> сотен тысяч объектов мы не производили так как не было такой потребности в
>>>> прикладных задачах, но думаю да это один из минусов. Вообще мы
>>>> позиционировали свой движок на малые и средние реализации. Однако
>>>> незначительное число web-разработчиков испытывающих наше решение признали
>>>> что мы быстрее привычных для них реализаций.
>>>>
>>>> вт, 15 июн. 2021 г. в 20:15, Dmitriy Resnyanskiy <zubosem(at)gmail(dot)com>:
>>>>
>>>>> Добрый день.
>>>>> Спасибо что ознакомились. Постгрес действительно разительно отличается
>>>>> от мускула возможностями. Как мне кажется, такое решение мы не смогли бы
>>>>> реализовать на мускуле. Исходили из того, что всегда хочется реляционных
>>>>> возможностей и гибкости в расширении таблиц.
>>>>> Но в том числе ваш ответ дает нам понять, что это не дичь. Мы
>>>>> попробовали эту структуру на Фиасе, получилось очень быстро. Вставлялся
>>>>> неделю правда )
>>>>> Еще минус, конечно, трёхэтажные некрасивые селекты, но "дотянуться"
>>>>> можно быстро до любого значения. Ну и конечно агрегация всегда слабая в
>>>>> таких БД. Поэтому хотим использовать кликхаус для возможностей агрегации с
>>>>> подключением данной структуры как справочника.
>>>>> Готов сверять часы, так сказать, обмениваться мнениями.
>>>>> Спасибо за ваш ответ.
>>>>>
>>>>>
>>>>> вт, 15 июн. 2021 г., 17:28 Дмитрий Иванов <firstdismay(at)gmail(dot)com>:
>>>>>
>>>>>> Добрый день, Дмитрий.
>>>>>> Как Дмитрий Дмитрию скажу что Ваш подход вполне жизнеспособен. Над
>>>>>> предложенным Вами вариантом я работаю с 2012 года
>>>>>> использование фиксированных проприетарно индексированных таблиц для
>>>>>> хранения расширенных свойств сущностей с заведомо
>>>>>> неизвестной структурой имеет ряд своих недостатков, однако переход на
>>>>>> PostgreSQL вдохнул новую жизнь в наше первое решение
>>>>>> мы реализовали многоуровневое наследование, библиотеку
>>>>>> файловых документов с использованием интерфейса БД (без больших объектов
>>>>>> при этом)
>>>>>> и много чего еще интересного, на мой взгляд плюсы перевешивают минусы.
>>>>>> Раз вы пришли независимо к такому решению возможно было бы интересно
>>>>>> обменяться соображениями.
>>>>>> API первой версии у нас реализовано на порядка 947 процедурах и
>>>>>> работает под MS SQL с использованием файлового сервера.
>>>>>> Новое решение еще в разработке порядка 671 функции.
>>>>>>
>>>>>> ---------- Forwarded message ---------
>>>>>> От: Михаил <m(dot)nasedkin(at)gmail(dot)com>
>>>>>> Date: вт, 15 июн. 2021 г. в 09:35
>>>>>> Subject: Re: Особый способ хранения в базах Postgres
>>>>>> To: Dmitriy Resnyanskiy <zubosem(at)gmail(dot)com>
>>>>>> Cc: <pgsql-ru-general(at)lists(dot)postgresql(dot)org>
>>>>>>
>>>>>>
>>>>>> Я тоже такими вещами занимался, когда по молодости кровь кипела, а
>>>>>> проектов толком не было. Вариаций на данную тему миллион. Вашу работу
>>>>>> одобряю. Мало кто захочет ее применять, потому что, например, я сейчас
>>>>>> в около средней конторе, где бэк-программисты вообще не видят чистого
>>>>>> скуля, с БД оперируют модельные обертки. А мне приходится смотреть на
>>>>>> это в тоске и печали.
>>>>>>
>>>>>> Благ и удачи.
>>>>>>
>>>>>> 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. Трехэтажными джоинами по индексированным полям можно быстро
>>>>>> > "дотянуться" до любых данных объекта.
>>>>>> >
>>>>>> > Нам очень интересно ваше мнение о проделанной работе.
>>>>>> Пожалуйста,взгляните
>>>>>> > на нее экспертным взглядом и укажите на проблемы и недостатки такого
>>>>>> > подхода.
>>>>>> > Возможно, уже давно есть технологии, фреймворки, которые
>>>>>> отталкиваются от
>>>>>> > тех же задач и проблем, пожалуйста, дайте ссылки на них почитать.
>>>>>> > Код не претендует на совершенство и, скорее всего, стоит надеть
>>>>>> специальный
>>>>>> > костюм ассенизатора, прежде чем туда заглянуть ;)
>>>>>> > Не судите строго, большое спасибо.
>>>>>> >
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ---
>>>>>> С уважением,
>>>>>> Михаил Наседкин
>>>>>>
>>>>>