Это практически нельзя.
У меня получилось как раз потому, что это никто нигде пока не сделал именно так.
Я не отрицаю, что схема необыкновенно проста и очевидна, и любой мог бы её запатентовать ранее, если бы построил пару индексов и запихнул всё в одну таблицу. Но почему-то никто этого не сделал ни в РФ, ни за рубежом. Допускаю, что это просто никому не было нужно.
Должно быть, вы думаете, что легко получить такую вот бумажку
Подскажите, пожалуйста, случай, в котором это может понадобиться? Просто интересно, чем будет ограничена выборка этой рекурсии.
Например, в структуре рекрутерского проекта все данные взаимосвязаны, что неудивительно для реляционной базы. То есть, рекурсивно они выберутся практически все — все метаданные.
Когда мне нужен некий фрагмент этой структуры, то я укажу явно, какие сущности нужны.
Если нужно присоединить одну сущность с разными целями, то можно использовать подобие ALIASа, как в обычном SELECT.
Например, как это сделано в демо-кладре, где есть отчет с ссылкой на одну и ту же таблицу как на город, республику или регион (см.колонку Alias):
Будет, к примеру, такой запрос:
SELECT a171.val v1_171,a194.val v2_194,a202.val v3_202,a207.val v4_202,a197.val v5_194,a181.val v6_171,a171_region.val v9_171,a171_area.val v12_171
FROM kladr a171
LEFT JOIN (kladr r194 JOIN kladr a194 USE INDEX (PRIMARY)) ON r194.up=a194.id AND a171.id=r194.t AND a194.t=194
LEFT JOIN (kladr r202 JOIN kladr a202 USE INDEX (PRIMARY)) ON r202.up=a202.id AND a194.id=r202.t AND a202.t=202
LEFT JOIN kladr a207 ON a207.up=a202.id AND a207.t=207
LEFT JOIN kladr a197 ON a197.up=a194.id AND a197.t=197
LEFT JOIN kladr a181 ON a181.up=a171.id AND a181.t=181
LEFT JOIN (kladr r187 JOIN kladr a187 USE INDEX (PRIMARY)) ON r187.up=a171.id AND a187.id=r187.t AND a187.t=171
LEFT JOIN kladr a171_region ON a171_region.t=171 AND a171_region.id=a187.id
LEFT JOIN (kladr r187_region JOIN kladr a187_region USE INDEX (PRIMARY)) ON r187_region.up=a171_region.id AND a187_region.id=r187_region.t AND a187_region.t=171
LEFT JOIN kladr a171_area ON a171_area.t=171 AND a171_area.id=a187_region.id
WHERE a171.up!=0 AND length(a171.val) AND a171.t=171 AND a171_region.val LIKE 'Надым%' LIMIT 20;
Как работает построитель запросов:
1. Вы выбираете любую сущность и справочника
2. Система в один запрос выберет список всех ее полей, включая те, что являются связями
3. Вы можете выбрать любую сущность, которая связана с выбранными ранее (конструктор ограничит выбор)
4. Переходим к п.2 для выбора следующей сущности, пока не соберем весь набор полей для запроса
5. Теперь мы имеем список, по которому система в один запрос выберет список всех полей выбранных сущностей
Да.
Они все перечислены в таблице Колонки отчета в построителе запросов.
Если вы имеете в виду, что у баз данных есть ограничения по количеству JOIN, то тут — да (в том же MSSQL, вроде, не более 256 объединений), поэтому далее при построении запроса с большим количеством полей будет ошибка.
И это, собственно, ответ на мой вопрос: вы используете иерархические сущности (вопреки тому, что я предполагал по ранним примерам), поэтому мои вопросы к полю ID неуместны.
Я не до конца понял в чем была задача этого упражнения, но про иерархические сущности признаю, что один существенный момент не был явно упомянут в статьях и не фигурировал в вопросах к ним.
Суть в том что ядро не пробегается последовательно по иерархии при построении запроса (например, того, что описан в примере с книгами), а одним махом выбирает весь набор полей данных, которые используются в запросе, при любом количестве уровней иерархии.
В этом наборе есть вся информация для построения запроса с необходимыми JOIN, что отчетливо видно в тексте запроса.
Можно пойти дальше — реализовать всё в двух колонках одной таблицы (id, json), или в одном поле одной записи (за счет JSON поля).
Это как раз будет KV (key-value)
И запатентовать ;)
Кстати, попробуйте!
В комментариях здесь неоднократно выражалась печаль, что, якобы, можно что угодно запатентовать. Правда есть одна пикантная особенность — те же люди признаются, что не разбираются в теме патентования.
Возьмите простейший замусоленный здесь пример с книгами и авторами
Я взял пример из патента, зачем мне брать другой пример? Но ок, позже попробую.
Не забудьте здесь рассказать про результат, пожалуйста.
Статья опубликована, в основном, для этого — подтверждение или опровержение наличия полных архитектурных аналогов.
Мне, знаете ли, искренне лень разбираться, где в этом патенте описание технического решения, а где — что. Я изначально и написал, что меня расстраивают документ и факт патента при таком описании в документе.
Это чистый слив. Как вы можете утверждать про неоднозначность, если вам лень разобраться?
Так и пишите, что вам лень.
Ага, понятно.
То есть вас эти формулировки огорчают, а к описанию технического решения про поля и связи претензий нет. То есть, там всё однозначно.
Только непонятно, чем вас вот это не устроило:
А вот типичный пример «implementation-defined»:
Человеку, имеющему навыки в данной области техники, понятно, что указанный порядок заполнения строк и столбцов дан в качестве примера и служит для целей описания сущности изобретения. В каждом конкретном случае порядок строк и столбцов может быть иным в зависимости от последовательности добавления, изменения и удаления информации из таблицы.
Ну да, порядок колонок и строк может быть любым. Что здесь не так?
Там каждый тип термина фигурирует в единственном экземпляре, поэтому Заказчик упомянут только ссылкой на него, так как это равноценный Договору тип.
Я дал вам ниже картинку, чтобы проще было.
Ровно до момента «а давайте...» и мечта становится кошмаром
Статья написана по итогам тестирования решения, в том числе тех обычно «кошмарных» кейсов, которые удалось нормально выполнить.
такое бывает, но не в ваших системах, потому как использовать их на терабайтных базах будет только безумец (сотни таблиц, миллионы записей при десятках полей десятка разных типов, часть из которых индексировать не надо в принципе и запрос выборки среднего значения поля с простой фильтрацией)
Для терабайтных баз существует масса типовых решений для разных случаев:
а) для аналитики: базы предагрегированных данных несоизмеримо меньшего объема
б) для архивного хранения: неиндексированные хранилища
в) для исследований: специализированные базы (колоночные, например)
г)…
Если же база объективно велика и не может быть покрыта специализированным решением, то часто можно наблюдать картину, когда размер индексов многократно превышает размер данных. В таких случаях использование этого конструктора вполне себе оправдано.
В предыдущей статье я рассказывал о сервисе, который сложнее прототипа, и он вполне себе нормально работает под типичной загрузкой 20-30 пользователей одновременно.
Вы как бы в профессиональном сообществе и находитесь.
Спалились на «как бы».
Там вполне однозначная трактовка в формуле. Язык несколько необычен, что смущает по первости, и неудивительно. Но неоднозначностей там нет, если читать внимательно и аккуратно.
У меня получилось как раз потому, что это никто нигде пока не сделал именно так.
Я не отрицаю, что схема необыкновенно проста и очевидна, и любой мог бы её запатентовать ранее, если бы построил пару индексов и запихнул всё в одну таблицу. Но почему-то никто этого не сделал ни в РФ, ни за рубежом. Допускаю, что это просто никому не было нужно.
Так. И как это делается в реляционной БД так, чтобы я не мог то же самое повторить в конструкторе?
Подскажите, пожалуйста, случай, в котором это может понадобиться? Просто интересно, чем будет ограничена выборка этой рекурсии.
Например, в структуре рекрутерского проекта все данные взаимосвязаны, что неудивительно для реляционной базы. То есть, рекурсивно они выберутся практически все — все метаданные.
Когда мне нужен некий фрагмент этой структуры, то я укажу явно, какие сущности нужны.
Например, как это сделано в демо-кладре, где есть отчет с ссылкой на одну и ту же таблицу как на город, республику или регион (см.колонку Alias):
Будет, к примеру, такой запрос:
И такой результат:
1. Вы выбираете любую сущность и справочника
2. Система в один запрос выберет список всех ее полей, включая те, что являются связями
3. Вы можете выбрать любую сущность, которая связана с выбранными ранее (конструктор ограничит выбор)
4. Переходим к п.2 для выбора следующей сущности, пока не соберем весь набор полей для запроса
5. Теперь мы имеем список, по которому система в один запрос выберет список всех полей выбранных сущностей
Они все перечислены в таблице Колонки отчета в построителе запросов.
Если вы имеете в виду, что у баз данных есть ограничения по количеству JOIN, то тут — да (в том же MSSQL, вроде, не более 256 объединений), поэтому далее при построении запроса с большим количеством полей будет ошибка.
Я не до конца понял в чем была задача этого упражнения, но про иерархические сущности признаю, что один существенный момент не был явно упомянут в статьях и не фигурировал в вопросах к ним.
Суть в том что ядро не пробегается последовательно по иерархии при построении запроса (например, того, что описан в примере с книгами), а одним махом выбирает весь набор полей данных, которые используются в запросе, при любом количестве уровней иерархии.
В этом наборе есть вся информация для построения запроса с необходимыми JOIN, что отчетливо видно в тексте запроса.
Это как раз будет KV (key-value)
Кстати, попробуйте!
В комментариях здесь неоднократно выражалась печаль, что, якобы, можно что угодно запатентовать. Правда есть одна пикантная особенность — те же люди признаются, что не разбираются в теме патентования.
Не забудьте здесь рассказать про результат, пожалуйста.
Статья опубликована, в основном, для этого — подтверждение или опровержение наличия полных архитектурных аналогов.
Это чистый слив. Как вы можете утверждать про неоднозначность, если вам лень разобраться?
Так и пишите, что вам лень.
То есть вас эти формулировки огорчают, а к описанию технического решения про поля и связи претензий нет. То есть, там всё однозначно.
Только непонятно, чем вас вот это не устроило:
Ну да, порядок колонок и строк может быть любым. Что здесь не так?
Я дал вам ниже картинку, чтобы проще было.
Статья написана по итогам тестирования решения, в том числе тех обычно «кошмарных» кейсов, которые удалось нормально выполнить.
Для терабайтных баз существует масса типовых решений для разных случаев:
а) для аналитики: базы предагрегированных данных несоизмеримо меньшего объема
б) для архивного хранения: неиндексированные хранилища
в) для исследований: специализированные базы (колоночные, например)
г)…
Если же база объективно велика и не может быть покрыта специализированным решением, то часто можно наблюдать картину, когда размер индексов многократно превышает размер данных. В таких случаях использование этого конструктора вполне себе оправдано.
Спалились на «как бы».
Там вполне однозначная трактовка в формуле. Язык несколько необычен, что смущает по первости, и неудивительно. Но неоднозначностей там нет, если читать внимательно и аккуратно.
А вот вторая позиция с одним размещением: