Вывод. Структура базы данных, описанная в патенте, является реализацией EAV, так как их можно преобразовать одну в другую простыми и обратимыми преобразованиями, которые в большинстве случаев сводятся к помещению данных в поле с другим названием. Следовательно, она не может являться чьим-то изобретением или его частью, включая названия, назначение полей, необходимые индексы, и их эквивалентные модификации.
Структура не является изобретением, что делает неверным ваши последующие выводы.
То, что вы сделали, называется миграцией данных, и это можно сделать из любой системы в любую систему, как в одну сторону, так и в другую. Да, вы загрузили все данные в одну таблицу, только это не работает так же, как я описываю — получился бессвязный массив каких-то данных. Не говоря уже об ошибках сопоставления. Что за «Договор» у вас в выпадающем списке?
В статье описана не структура, а подход к организации данных — мы храним единообразно все типы, все мета-данные, все данные и их связи. Это позволяет не писать код, конфигурируя структуру данных и задавая выборки. В сравнении с той же Magento сразу бросаются в глаза названия таблиц типа catalog_product_entity_varchar, то есть, вам нужно хардкодить где какой атрибут хранится и как к нему обращаться. Это иной принцип хранения и выборки, нежели описанный мной, пусть он и похож структурой.
Некорректный вопрос, типа: «Чем отличается канал от канализации».
Что такое EAV?
Что такое Система хранения данных и способ выборки?
Ответьте на эти два вопроса в ваших терминах и увидите разницу.
Не будет разницы в ваших терминах — считайте, что это одно и то же. Будет — тем лучше.
И в любом случае получите ответ на свой вопрос.
Слишком много «если».
Описанный здесь подход нигде не используется в точно таком виде.
Если вдруг начнет использоваться после появления этой статьи, то тогда будет что обсудить.
Если мне заплатят, то я могу все таблицы Magento с их данными свести к одному Adjacency List, который будет содержать всю информацию для
Собственно, я примерно так и сделал, сам себе заплатив. А затем добился работоспособности всего этого, создав индексы и алгоритм выборки.
Получилась система, отличная от Magento, и никто ничего не нарушает в данном случае.
Патентом защищена система: структура из 4 полей (Order — необязательное поле) с этими индексами и принцип выборки из этой единой таблицы.
Если, например, кто-то сделает отдельные таблицы под разные типы (и размерность) данных, чтобы работал индексируемый поиск по диапазонам чисел, и будет делать JOIN разных таблиц, в зависимости от базового типа данных, то это будет в рамках этого патента.
Аналогично, если добавить поля в эту таблицу или кластеризовать её: разнести диапазоны, покрытые индексами, на разные сервера, например, то это также нарушение патентного права.
Убираете из таблицы любое из обязательных 4 полей или индекс — всё, это уже не изобретение, о котором мы тут рассуждаем.
Я повторяю свою просьбу. Напишите отдельным комментарием список основных отличий вашего решения от EAV как подхода к хранению и его реализации на примере допустим Magento.
Вот что написано в статье:
Все данные физически хранятся в одной таблице из 5 полей: ID, родитель (ID), тип (тоже ID), порядок среди равных (число), значение (набор байтов). У неё есть 3 индекса: ID, тип-значение, родитель-тип. Вместо обращения к базе данных, которая найдет таблицу, в ней найдет поле, в котором найдет данные, ядро обращается к единственной таблице, в которой по индексу сразу находит данные нужного типа.
Идем в Маженту, ищем там таблицу с такими полями и такими индексами. Ну вот, скажем, индекс тип-значение есть хоть где-то?
Это не таблица, это выборка из таблиц.
Трансформация структуры — это когда вы переставляете столбцы, денормализуете или нормализуете таблицы, объединяете поля данных или разделяете их. При этом не происходит потери данных, а сама конечная структура содержит всю информацию для однозначного обратного преобразования.
Но это не главное. Вам следует уяснить, что набор полей — это только набор полей, и он не может быть защищен авторским правом или патентом.
Осмелюсь заявить, что это вы не понимаете.
Чем отличается от EAV, EAV/CR, KV и иже с ними, я уже отчаялся объяснить.
Давайте так сформулирую: ни одно существующее ныне решение не будет ущемлено этим патентом. Просто потому что они с ним не конфликтуют.
Годится?
Система — это не только структура.
Даже структуру многие комментаторы здесь трактуют неверно, редуцированно. Систему же в целом они совсем отказываются понимать.
Структура не является изобретением, что делает неверным ваши последующие выводы.
То, что вы сделали, называется миграцией данных, и это можно сделать из любой системы в любую систему, как в одну сторону, так и в другую. Да, вы загрузили все данные в одну таблицу, только это не работает так же, как я описываю — получился бессвязный массив каких-то данных. Не говоря уже об ошибках сопоставления. Что за «Договор» у вас в выпадающем списке?
В статье описана не структура, а подход к организации данных — мы храним единообразно все типы, все мета-данные, все данные и их связи. Это позволяет не писать код, конфигурируя структуру данных и задавая выборки. В сравнении с той же Magento сразу бросаются в глаза названия таблиц типа catalog_product_entity_varchar, то есть, вам нужно хардкодить где какой атрибут хранится и как к нему обращаться. Это иной принцип хранения и выборки, нежели описанный мной, пусть он и похож структурой.
Для начала добавить индекс и посмотреть, что будет.
Потом можете подать иск (не знаю, к кому и на что, ибо это не моя идея, а ваша).
Надо пробовать.
Я предоставил всю информацию для однозначного суждения.
Что такое EAV?
Что такое Система хранения данных и способ выборки?
Ответьте на эти два вопроса в ваших терминах и увидите разницу.
Не будет разницы в ваших терминах — считайте, что это одно и то же. Будет — тем лучше.
И в любом случае получите ответ на свой вопрос.
Описанный здесь подход нигде не используется в точно таком виде.
Если вдруг начнет использоваться после появления этой статьи, то тогда будет что обсудить.
Закрыт ли теперь этот вопрос?
Собственно, я примерно так и сделал, сам себе заплатив. А затем добился работоспособности всего этого, создав индексы и алгоритм выборки.
Получилась система, отличная от Magento, и никто ничего не нарушает в данном случае.
Если, например, кто-то сделает отдельные таблицы под разные типы (и размерность) данных, чтобы работал индексируемый поиск по диапазонам чисел, и будет делать JOIN разных таблиц, в зависимости от базового типа данных, то это будет в рамках этого патента.
Аналогично, если добавить поля в эту таблицу или кластеризовать её: разнести диапазоны, покрытые индексами, на разные сервера, например, то это также нарушение патентного права.
Убираете из таблицы любое из обязательных 4 полей или индекс — всё, это уже не изобретение, о котором мы тут рассуждаем.
Вот что написано в статье:
Идем в Маженту, ищем там таблицу с такими полями и такими индексами. Ну вот, скажем, индекс тип-значение есть хоть где-то?
Трансформация структуры — это когда вы переставляете столбцы, денормализуете или нормализуете таблицы, объединяете поля данных или разделяете их. При этом не происходит потери данных, а сама конечная структура содержит всю информацию для однозначного обратного преобразования.
Но это не главное.
Вам следует уяснить, что набор полей — это только набор полей, и он не может быть защищен авторским правом или патентом.
По существу: по таймингу или плану запроса есть замечиния?
Иначе слив засчитан.
Чем отличается от EAV, EAV/CR, KV и иже с ними, я уже отчаялся объяснить.
Давайте так сформулирую: ни одно существующее ныне решение не будет ущемлено этим патентом. Просто потому что они с ним не конфликтуют.
Годится?
Даже структуру многие комментаторы здесь трактуют неверно, редуцированно. Систему же в целом они совсем отказываются понимать.
Структуру данных запатентовать нельзя, во всяком случае в РФ.
Это я к тому, что вы не разобрались в сути статьи.
Нужен алгоритм, который строит запросы и прорисовывает интерфейс.
Вот этот интерфейс (ссылка с ролью админа):
https://tryint.ru/index.php?db=test&secret=0t1e2s3t4