Вот только этот случай к вашей гипотезе отношения не имеет, потому что объем данных не изменился.
Изменилась Сложность — добавился некий отчет, не повлиявший на объем, но увеличивший нагрузку на ресурсы.
Более того, немного выше по тексту есть случай, где производительность конструктора внезапно в 17 раз хуже. Этот пример в вашей гипотезе как отражен?
Этот пример отражен в начале графика — изначально конструктор требует в разы больше ресурсов.
Причина конкретно этого случая известна и её легко устранить, как я показываю в примере.
Сразу же вопрос — по каким данным построен этот график? Предоставьте данные исследований, пожалуйста. Графики, нарисованные от балды, не являются доказательством чего-либо, особенно в статье про отличие от существующих решений.
Это иллюстрация, картинка. Там нет чисел, а только отражена гипотеза.
В статье работа гипотезы рассматривается на примере: в каких-то случаях производительность обычной БД внезапно в 30 раз хуже, чем в конструкторе.
Кроме того, вы не можете запрещать патентом ставить кому-то произвольные индексы. Потому что эта функциональность в СУБД разработана не вами. Вот если бы вы свой тип индекса написали, тогда могли бы его запатентовать.
Кто вам чего запрещает? Цель этого всего — как раз сделать публичное свободное решение и развивать его, о чем я сейчас пытаюсь договориться с потенциальными партнерами.
Патент защищает решение от того, чего вы опасаетесь, если я правильно вас понял.
Если хоть одно условие не соответствует, то значит это не является модификацией вашей системы? Ну например, если типы хранятся в другой таблице?
Вы опять рассуждаете о структуре, а это только 3 пункта из приведенных мной 10.
Если вы считаете, что иной, опишите все отличия от вашего принципа. Чтобы по этому списку отличий можно было проверить любой другой принцип хранения и выборки на нарушение или ненарушение вашего патента.
catalog_product_entity_varchar, catalog_product_entity_int… это отдельные таблицы для типа данных. Если вы считаете, что иной, опишите все отличия от вашего принципа. Чтобы по этому списку отличий можно было проверить любой другой принцип хранения и выборки на нарушение или ненарушение вашего патента.
Хорошо, я составлю краткий список для обнаружения отличий — простой опросник на одну-две минуты.
Вывод. Структура базы данных, описанная в патенте, является реализацией EAV, так как их можно преобразовать одну в другую простыми и обратимыми преобразованиями, которые в большинстве случаев сводятся к помещению данных в поле с другим названием. Следовательно, она не может являться чьим-то изобретением или его частью, включая названия, назначение полей, необходимые индексы, и их эквивалентные модификации.
Структура не является изобретением, что делает неверным ваши последующие выводы.
То, что вы сделали, называется миграцией данных, и это можно сделать из любой системы в любую систему, как в одну сторону, так и в другую. Да, вы загрузили все данные в одну таблицу, только это не работает так же, как я описываю — получился бессвязный массив каких-то данных. Не говоря уже об ошибках сопоставления. Что за «Договор» у вас в выпадающем списке?
В статье описана не структура, а подход к организации данных — мы храним единообразно все типы, все мета-данные, все данные и их связи. Это позволяет не писать код, конфигурируя структуру данных и задавая выборки. В сравнении с той же Magento сразу бросаются в глаза названия таблиц типа catalog_product_entity_varchar, то есть, вам нужно хардкодить где какой атрибут хранится и как к нему обращаться. Это иной принцип хранения и выборки, нежели описанный мной, пусть он и похож структурой.
Некорректный вопрос, типа: «Чем отличается канал от канализации».
Что такое EAV?
Что такое Система хранения данных и способ выборки?
Ответьте на эти два вопроса в ваших терминах и увидите разницу.
Не будет разницы в ваших терминах — считайте, что это одно и то же. Будет — тем лучше.
И в любом случае получите ответ на свой вопрос.
Слишком много «если».
Описанный здесь подход нигде не используется в точно таком виде.
Если вдруг начнет использоваться после появления этой статьи, то тогда будет что обсудить.
Если мне заплатят, то я могу все таблицы Magento с их данными свести к одному Adjacency List, который будет содержать всю информацию для
Собственно, я примерно так и сделал, сам себе заплатив. А затем добился работоспособности всего этого, создав индексы и алгоритм выборки.
Получилась система, отличная от Magento, и никто ничего не нарушает в данном случае.
Патентом защищена система: структура из 4 полей (Order — необязательное поле) с этими индексами и принцип выборки из этой единой таблицы.
Если, например, кто-то сделает отдельные таблицы под разные типы (и размерность) данных, чтобы работал индексируемый поиск по диапазонам чисел, и будет делать JOIN разных таблиц, в зависимости от базового типа данных, то это будет в рамках этого патента.
Аналогично, если добавить поля в эту таблицу или кластеризовать её: разнести диапазоны, покрытые индексами, на разные сервера, например, то это также нарушение патентного права.
Убираете из таблицы любое из обязательных 4 полей или индекс — всё, это уже не изобретение, о котором мы тут рассуждаем.
Я повторяю свою просьбу. Напишите отдельным комментарием список основных отличий вашего решения от EAV как подхода к хранению и его реализации на примере допустим Magento.
Вот что написано в статье:
Все данные физически хранятся в одной таблице из 5 полей: ID, родитель (ID), тип (тоже ID), порядок среди равных (число), значение (набор байтов). У неё есть 3 индекса: ID, тип-значение, родитель-тип. Вместо обращения к базе данных, которая найдет таблицу, в ней найдет поле, в котором найдет данные, ядро обращается к единственной таблице, в которой по индексу сразу находит данные нужного типа.
Идем в Маженту, ищем там таблицу с такими полями и такими индексами. Ну вот, скажем, индекс тип-значение есть хоть где-то?
Это не таблица, это выборка из таблиц.
Трансформация структуры — это когда вы переставляете столбцы, денормализуете или нормализуете таблицы, объединяете поля данных или разделяете их. При этом не происходит потери данных, а сама конечная структура содержит всю информацию для однозначного обратного преобразования.
Но это не главное. Вам следует уяснить, что набор полей — это только набор полей, и он не может быть защищен авторским правом или патентом.
Да, давайте сравним легкость на примере. Я устранил причину в 1 клик, переместив колонку отчета.
Изменилась Сложность — добавился некий отчет, не повлиявший на объем, но увеличивший нагрузку на ресурсы.
Этот пример отражен в начале графика — изначально конструктор требует в разы больше ресурсов.
Причина конкретно этого случая известна и её легко устранить, как я показываю в примере.
Это иллюстрация, картинка. Там нет чисел, а только отражена гипотеза.
В статье работа гипотезы рассматривается на примере: в каких-то случаях производительность обычной БД
внезапнов 30 раз хуже, чем в конструкторе.Кто вам чего запрещает? Цель этого всего — как раз сделать публичное свободное решение и развивать его, о чем я сейчас пытаюсь договориться с потенциальными партнерами.
Патент защищает решение от того, чего вы опасаетесь, если я правильно вас понял.
Вы опять рассуждаете о структуре, а это только 3 пункта из приведенных мной 10.
Опубликовал ответ здесь
Хорошо, я составлю краткий список для обнаружения отличий — простой опросник на одну-две минуты.
Структура не является изобретением, что делает неверным ваши последующие выводы.
То, что вы сделали, называется миграцией данных, и это можно сделать из любой системы в любую систему, как в одну сторону, так и в другую. Да, вы загрузили все данные в одну таблицу, только это не работает так же, как я описываю — получился бессвязный массив каких-то данных. Не говоря уже об ошибках сопоставления. Что за «Договор» у вас в выпадающем списке?
В статье описана не структура, а подход к организации данных — мы храним единообразно все типы, все мета-данные, все данные и их связи. Это позволяет не писать код, конфигурируя структуру данных и задавая выборки. В сравнении с той же Magento сразу бросаются в глаза названия таблиц типа catalog_product_entity_varchar, то есть, вам нужно хардкодить где какой атрибут хранится и как к нему обращаться. Это иной принцип хранения и выборки, нежели описанный мной, пусть он и похож структурой.
Для начала добавить индекс и посмотреть, что будет.
Потом можете подать иск (не знаю, к кому и на что, ибо это не моя идея, а ваша).
Надо пробовать.
Я предоставил всю информацию для однозначного суждения.
Что такое EAV?
Что такое Система хранения данных и способ выборки?
Ответьте на эти два вопроса в ваших терминах и увидите разницу.
Не будет разницы в ваших терминах — считайте, что это одно и то же. Будет — тем лучше.
И в любом случае получите ответ на свой вопрос.
Описанный здесь подход нигде не используется в точно таком виде.
Если вдруг начнет использоваться после появления этой статьи, то тогда будет что обсудить.
Закрыт ли теперь этот вопрос?
Собственно, я примерно так и сделал, сам себе заплатив. А затем добился работоспособности всего этого, создав индексы и алгоритм выборки.
Получилась система, отличная от Magento, и никто ничего не нарушает в данном случае.
Если, например, кто-то сделает отдельные таблицы под разные типы (и размерность) данных, чтобы работал индексируемый поиск по диапазонам чисел, и будет делать JOIN разных таблиц, в зависимости от базового типа данных, то это будет в рамках этого патента.
Аналогично, если добавить поля в эту таблицу или кластеризовать её: разнести диапазоны, покрытые индексами, на разные сервера, например, то это также нарушение патентного права.
Убираете из таблицы любое из обязательных 4 полей или индекс — всё, это уже не изобретение, о котором мы тут рассуждаем.
Вот что написано в статье:
Идем в Маженту, ищем там таблицу с такими полями и такими индексами. Ну вот, скажем, индекс тип-значение есть хоть где-то?
Трансформация структуры — это когда вы переставляете столбцы, денормализуете или нормализуете таблицы, объединяете поля данных или разделяете их. При этом не происходит потери данных, а сама конечная структура содержит всю информацию для однозначного обратного преобразования.
Но это не главное.
Вам следует уяснить, что набор полей — это только набор полей, и он не может быть защищен авторским правом или патентом.