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

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

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