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

Добрый день.
Связывание сущностей делается средствами СУБД, т.е. в дочерний объект
добавляется поле parent с указанием идентификатора родителя или другой
способ: в поле родителя с типом BIGINT[] добавляются идентификаторы детей.
Понимание созданной структуры программистом конечно обязательно для
правильной выемки объектов и работы со связями. Однако, в самой новой
ревизии мы добавили в таблицу ключей объектов тип link, который
дополнительно проверяется при сохранении и выемке объектов функциями и
позволяет и сохранять и и извлекать связанные объекты за раз.

ср, 23 июн. 2021 г., 17:57 Дмитрий Иванов <firstdismay(at)gmail(dot)com>:

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