Можно пойти дальше — реализовать всё в двух колонках одной таблицы (id, json), или в одном поле одной записи (за счет JSON поля).

Это как раз будет KV (key-value)

И запатентовать ;)

Кстати, попробуйте!

В комментариях здесь неоднократно выражалась печаль, что, якобы, можно что угодно запатентовать. Правда есть одна пикантная особенность — те же люди признаются, что не разбираются в теме патентования.

Возьмите простейший замусоленный здесь пример с книгами и авторами

Я взял пример из патента, зачем мне брать другой пример? Но ок, позже попробую.

Не забудьте здесь рассказать про результат, пожалуйста.
Статья опубликована, в основном, для этого — подтверждение или опровержение наличия полных архитектурных аналогов.

Как истинный «как бы» профессионал вы, ничего не понимая в теме и поленившись читать, критикуете.

Мне, знаете ли, искренне лень разбираться, где в этом патенте описание технического решения, а где — что. Я изначально и написал, что меня расстраивают документ и факт патента при таком описании в документе.

Это чистый слив. Как вы можете утверждать про неоднозначность, если вам лень разобраться?
Так и пишите, что вам лень.

Ага, понятно.
То есть вас эти формулировки огорчают, а к описанию технического решения про поля и связи претензий нет. То есть, там всё однозначно.

Только непонятно, чем вас вот это не устроило:

А вот типичный пример «implementation-defined»:

Человеку, имеющему навыки в данной области техники, понятно, что указанный порядок заполнения строк и столбцов дан в качестве примера и служит для целей описания сущности изобретения. В каждом конкретном случае порядок строк и столбцов может быть иным в зависимости от последовательности добавления, изменения и удаления информации из таблицы.

Ну да, порядок колонок и строк может быть любым. Что здесь не так?

В неоднозначных местах, где вы их видите

Я вам предлагаю ответить за свои слова и указать на неоднозначно трактуемые места в тексте

Там каждый тип термина фигурирует в единственном экземпляре, поэтому Заказчик упомянут только ссылкой на него, так как это равноценный Договору тип.
Я дал вам ниже картинку, чтобы проще было.

Ровно до момента «а давайте...» и мечта становится кошмаром

Статья написана по итогам тестирования решения, в том числе тех обычно «кошмарных» кейсов, которые удалось нормально выполнить.

такое бывает, но не в ваших системах, потому как использовать их на терабайтных базах будет только безумец (сотни таблиц, миллионы записей при десятках полей десятка разных типов, часть из которых индексировать не надо в принципе и запрос выборки среднего значения поля с простой фильтрацией)

Для терабайтных баз существует масса типовых решений для разных случаев:
а) для аналитики: базы предагрегированных данных несоизмеримо меньшего объема
б) для архивного хранения: неиндексированные хранилища
в) для исследований: специализированные базы (колоночные, например)
г)…
Если же база объективно велика и не может быть покрыта специализированным решением, то часто можно наблюдать картину, когда размер индексов многократно превышает размер данных. В таких случаях использование этого конструктора вполне себе оправдано.

Размещение второй позиции вот так выглядит в словаре, если что:

В предыдущей статье я рассказывал о сервисе, который сложнее прототипа, и он вполне себе нормально работает под типичной загрузкой 20-30 пользователей одновременно.

Вы как бы в профессиональном сообществе и находитесь.

Спалились на «как бы».

Там вполне однозначная трактовка в формуле. Язык несколько необычен, что смущает по первости, и неудивительно. Но неоднозначностей там нет, если читать внимательно и аккуратно.

В таблице выше видна одна позиция и её два размещения.
А вот вторая позиция с одним размещением:

Проблема в том, что — для специалиста — трактовка этого документа совершенно неоднозначна. Я, если честно, вообще расстроен, что у нас можно такое патентовать.

Для специалиста? Давайте покажем специалисту, послушаем его.
Вы обвиняете в непрофессионализме людей и целые организации — ФИПС и канадскую компанию, проводившие патентный поиск и содействующие в составлении формулы. При этом вы же не стесняетесь заявить, что ничего не понимаете в патентном праве.

Хотя я, пожалуй, постою в сторонке в вашем споре с ними.

Вот так

А в вашем чек-листе нет ни слова про интерфейс.
Причем здесь вообще внешний вид? Его можно какой угодно сделать. Даже используя ваш код, с расширениями браузера типа Stylish. Если я скачаю движок Интеграла и слегка поменяю HTML+CSS, это не нарушит патент? Думаю, нарушит. Значит интерфейс в сравнении участвовать не должен.

Я не про интерфейс говорю, а про содержание: значения полей Договор, Сумма, Предмет, Заказчик. Где у вас всё это?

Вот это имелось в виду?

Описание типов:


Объекты типов:

Ну нет, спасибо. Я эту «мечту программиста» дважды писал, и, как программист, больше никогда не хочу ее видеть (в сколь-нибудь сложных LOB-решениях).

Вот она в чём проблема. Лично ваша проблема, которую вы проецируете на увиденное здесь.
Вы пробовали, результат вам не понравился, значит и у других получиться ничего путного не может. Знакомо.

Я тоже поделюсь. Когда в 1998 году я пришел инженером на автозавод после института и армии, я загорелся сделать бесконтактный прерыватель указателя поворотов. И тогда взрослый инженер, под полтос, сказал мне не тратить время. В качестве доказательства он привел похожий аргумент: я пробовал, не получилось. Транзисторы горят, у тиристоров большие потери… Но у меня в итоге получилось, хотя я применил пару решений, за которые был критикуем. Например, я запараллелил пару транзисторов, а у них разный коэффициент передачи, плавающие характеристики, ну и прочие в общем случае правильные вещи услышал я от коллег. Тем не менее, в том конкретном случае такое решение было оправдано и мне удалось пройти все испытания: наработку на отказ, климатику (исполнение УХЛ: от -45 до +55 С) и прочие. Даже тогда я не слушал старпёров, теперь и подавно.

Давайте начнем по порядку.

Используется ли эта возможность в текущей реализации? Насколько я успел заметить, за пределами метаданных — нет. Иными словами, для прикладных данных у каждой сущности всегда есть ровно один уровень атрибутов, а все «вложенные» сущности (например, «книги автора») задаются через имитацию внешних ссылок (т.е., у сущности «книга» есть атрибут «author», в котором лежит идентификатор сущности «автор»). Если я не прав — покажите, как на уровне хранилища выглядят многоуровневые прикладные сущности.

Пример приведите, о чем речь, я его сделаю и продемонстрирую здесь.

Не нужно ничего дорабатывать. Только переименовать поля и разнести по таблицам, а это, как вы сами сказали, не учитывается.

Если ничего не нужно дорабатывать, давайте попробуем создать там такую схему данных и заполнить её:

Описание сущностей:


Экземпляры сущностей:


Редактор экземпляра: