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

Дмитрий, добрый день.
Простите за задержку с ответом. Забегался, никак до компьютера не доползу с
выходных )
Я в самом первом письме скидывал деплой схемы - это пока все, что у нас
есть.
Сейчас мы внедряем сразу в два собственных проекта. Внедрение покажет
результаты удобства использования.

вс, 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. Трехэтажными джоинами по индексированным полям можно быстро
>>>>> > "дотянуться" до любых данных объекта.
>>>>> >
>>>>> > Нам очень интересно ваше мнение о проделанной работе.
>>>>> Пожалуйста,взгляните
>>>>> > на нее экспертным взглядом и укажите на проблемы и недостатки такого
>>>>> > подхода.
>>>>> > Возможно, уже давно есть технологии, фреймворки, которые
>>>>> отталкиваются от
>>>>> > тех же задач и проблем, пожалуйста, дайте ссылки на них почитать.
>>>>> > Код не претендует на совершенство и, скорее всего, стоит надеть
>>>>> специальный
>>>>> > костюм ассенизатора, прежде чем туда заглянуть ;)
>>>>> > Не судите строго, большое спасибо.
>>>>> >
>>>>>
>>>>>
>>>>> --
>>>>> ---
>>>>> С уважением,
>>>>> Михаил Наседкин
>>>>>
>>>>