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

Про классы - что-то наподобие, наверно. Про интерфейсное проектирование мы
думали да, но это пока не первостепенно.

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

> << Понимание созданной структуры программистом конечно обязательно для
> правильной выемки объектов и работы со связями.>>
> Для этих целей мы создали среду визуального конструирования. Чтобы
> заложить основы базовой концепции описывающей предметную область просто без
> программирования. И позволить программисту реализующему целевой интерфейс
> и причитающуюся ему часть логической модели "заглядывать" внутрь концепции
> и менять ее по мере необходимости.
>
> Но ваши типы это аналог классов они описывают свойства объектов, объекты я
> правильно понимаю? Таким образом объект знает свой описывающий тип и свой
> контейнер при этом через ссылки он может быть связан с другими объектами? А
> объединение родственных типов? Дальше только на примерах из разных
> реализаций, например:
> Для целей технического учета существует потребность иметь изолированные
> типы оборудования, вто время как справочник номенклатуры (бухгалтерский
> учет) вводит понятие материал и объединяет все в одну кучу что дает
> возможность выполнять простой поиск по свойству "номенклатурный номер"
> (мыло, грабли, пасатижы), изолированые типы могут тоже иметь свойство
> "номенклатурный номер" но такие свойства не будут сопоставлены для разных
> типов (ну кроме как по имени). Если нужно и то и то и можно без хлеба
> (задвоения данных)?
>
> ср, 23 июн. 2021 г. в 19:15, Dmitriy Resnyanskiy <zubosem(at)gmail(dot)com>:
>
>> Добрый день.
>> Связывание сущностей делается средствами СУБД, т.е. в дочерний объект
>> добавляется поле 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. Трехэтажными джоинами по индексированным полям можно быстро
>>>>>>>>> > "дотянуться" до любых данных объекта.
>>>>>>>>> >
>>>>>>>>> > Нам очень интересно ваше мнение о проделанной работе.
>>>>>>>>> Пожалуйста,взгляните
>>>>>>>>> > на нее экспертным взглядом и укажите на проблемы и недостатки
>>>>>>>>> такого
>>>>>>>>> > подхода.
>>>>>>>>> > Возможно, уже давно есть технологии, фреймворки, которые
>>>>>>>>> отталкиваются от
>>>>>>>>> > тех же задач и проблем, пожалуйста, дайте ссылки на них почитать.
>>>>>>>>> > Код не претендует на совершенство и, скорее всего, стоит надеть
>>>>>>>>> специальный
>>>>>>>>> > костюм ассенизатора, прежде чем туда заглянуть ;)
>>>>>>>>> > Не судите строго, большое спасибо.
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> ---
>>>>>>>>> С уважением,
>>>>>>>>> Михаил Наседкин
>>>>>>>>>
>>>>>>>>