Проблема в том, что — для специалиста — трактовка этого документа совершенно неоднозначна. Я, если честно, вообще расстроен, что у нас можно такое патентовать.
Для специалиста? Давайте покажем специалисту, послушаем его.
Вы обвиняете в непрофессионализме людей и целые организации — ФИПС и канадскую компанию, проводившие патентный поиск и содействующие в составлении формулы. При этом вы же не стесняетесь заявить, что ничего не понимаете в патентном праве.
Хотя я, пожалуй, постою в сторонке в вашем споре с ними.
А в вашем чек-листе нет ни слова про интерфейс.
Причем здесь вообще внешний вид? Его можно какой угодно сделать. Даже используя ваш код, с расширениями браузера типа Stylish. Если я скачаю движок Интеграла и слегка поменяю HTML+CSS, это не нарушит патент? Думаю, нарушит. Значит интерфейс в сравнении участвовать не должен.
Я не про интерфейс говорю, а про содержание: значения полей Договор, Сумма, Предмет, Заказчик. Где у вас всё это?
Ну нет, спасибо. Я эту «мечту программиста» дважды писал, и, как программист, больше никогда не хочу ее видеть (в сколь-нибудь сложных LOB-решениях).
Вот она в чём проблема. Лично ваша проблема, которую вы проецируете на увиденное здесь.
Вы пробовали, результат вам не понравился, значит и у других получиться ничего путного не может. Знакомо.
Я тоже поделюсь. Когда в 1998 году я пришел инженером на автозавод после института и армии, я загорелся сделать бесконтактный прерыватель указателя поворотов. И тогда взрослый инженер, под полтос, сказал мне не тратить время. В качестве доказательства он привел похожий аргумент: я пробовал, не получилось. Транзисторы горят, у тиристоров большие потери… Но у меня в итоге получилось, хотя я применил пару решений, за которые был критикуем. Например, я запараллелил пару транзисторов, а у них разный коэффициент передачи, плавающие характеристики, ну и прочие в общем случае правильные вещи услышал я от коллег. Тем не менее, в том конкретном случае такое решение было оправдано и мне удалось пройти все испытания: наработку на отказ, климатику (исполнение УХЛ: от -45 до +55 С) и прочие. Даже тогда я не слушал старпёров, теперь и подавно.
Используется ли эта возможность в текущей реализации? Насколько я успел заметить, за пределами метаданных — нет. Иными словами, для прикладных данных у каждой сущности всегда есть ровно один уровень атрибутов, а все «вложенные» сущности (например, «книги автора») задаются через имитацию внешних ссылок (т.е., у сущности «книга» есть атрибут «author», в котором лежит идентификатор сущности «автор»). Если я не прав — покажите, как на уровне хранилища выглядят многоуровневые прикладные сущности.
Пример приведите, о чем речь, я его сделаю и продемонстрирую здесь.
Уважаемый, вы же сами видите, что в Magento эти пункты могли бы выполниться, если что-то добавить и смотреть с некоего угла, хотя это никто не пытался проверить на практике.
Вот, например:
Только переименовать поля и разнести по таблицам
При принципиально идентичных структурах переносить ничего не нужно: вы просто обращаетесь к полям под другими именами в нужных таблицах и все. Грубо говоря, берем ядро Интеграла или Magento и переписываем одно под другое (переименовываем поля и таблицы).
Не получается? Значит структуры и подход разные.
И да, уже «подводил» и уже заработало. Я описывал это здесь.
Заработало? Там даже статическая картинка Договора не похожа на оригинал.
Возьмите простейший замусоленный здесь пример с книгами и авторами, загрузите в Magento и выполните серию запросов, которые здесь приведены. Сразу поймете, насколько далеки Magento и Интеграл в архитектурном плане.
Да, я об этом же и говорю. Конструктор. Мечта программиста.
Как же так получилось, что в вашем решении понадобилось двигать колонки уже на 300Мб?
Не забывайте, что мы делали поиск при неприменимом индексе в миллионе записей. Есть простые правила, которые лучше выполнять, пользуясь конструктором, и я показал, как это работает и к чему приводит.
Можно было их и не выполнять, ничего страшного не случится.
(я даже не буду спрашивать, понимаете ли вы объективную разницу между 10Гб и 10Тб данных)
В 2003 году у нас было 13.5Тб в базе, и я многое понял тогда.
Прокомментировал те пункты, где вы явно сами признаете несовпадение.
Это как если бы вы рассуждали, что поезд — это мотоцикл, потому что на колесах и ездит. Только нужно доработать немного.
1, 3. В Magento несколько таблиц. Семантика полей совпадает с «ID, Parent ID, Type ID, Value», примеры я написал в первом комментарии. Практически у всего есть «идентификатор, родительский элемент, значение», а «тип элемента» может задаваться вынесением в таблицу специально для этого типа. Ничего не мешает и столбец сделать с одинаковым значением.
Вот когда зададут и сделают, тогда и будет о чем говорить. Пока же эти пункты не выполняются.
2. ID это первичный ключ, индекс на него есть во всех системах.
Индекс Parent ID + Type ID есть (entity_id + attribute_id в catalog_product_entity_varchar, attribute_set_id + attribute_id в eav_entity_attribute).
Индекса Type ID + Value нет в таблицах для товаров, но есть в других (attribute_id + value в eav_entity_*, entity_id + attribute_id + value в customer_address_entity_*) (пруф), а так же его может добавить администратор системы после установки.
Так пусть добавит, что же он раньше не добавлял?
5, 6, 7. С учетом п.3 аналогично — «одна из нескольких таблиц». В какой-то по-любому это хранится, а структуру любой можно подвести под семантику «ID, Parent ID, Type ID, Value».
Сначала подведите так, чтобы заработало.
10. Так как значения атрибутов хранятся в специальных таблицах для типов, то естественно выборка объектов по значению атрибутов требует указывать тип, в виде названия этой таблицы.
Тип в названии таблицы — хардкод, не вяжется с описанием типа в таблице.
Ага, я об этом и говорю. Документ этот описывает широкий круг существующих систем, и как следствие, их будущих аналогов. Значит создает возможности для патентного троллинга.
Укажите хоть одну систему, удовлетворяющую опроснику. Прямо по всем пунктам. Не по названиям полей, а по принципу хранения мета-данных и данных.
Я задал простой вопрос: «Если хоть одно условие не соответствует, значит ли это, что это уже другая система, а не модификация вашей?». Вариантов ответа всего 2 — да или нет (впрочем каждый из них порождает другие вопросы). Вы ни один не сказали.
Чек-лист сопровожден примечанием — должны выполняться 10 условий.
Мне неясно, как трактовать результаты применения. Допустим, у меня поля называются не parent_id, type_id, а abc_id, def_id, а все остальное то же самое. В чек-листе нет таких названий. Значит ли это, что у меня другая система, не ваша?
Извините, я вам не верю. Во-первых, потому что в прошлой статье всеми силами открещивались от модели EAV, а оказалось что она присутствует.
Я отрицал, что запатентована EAV. И сейчас придерживаюсь этого.
А во-вторых, потому что патент это официальный документ, а комментарии в интернете юридической силы не имеют.
Тут всё не так просто. Но в целом, совершенно не важно что я вам тут отвечу. Есть документ, объективная реальность, не зависящая от комментариев о нем в интернете.
Как минимум надо явно обозначить модификации, которые не являются нарушением патента. Я вас между прочим 2 раза уже спросил, но вы почему-то игнорируете.
Как же я игнорирую, если я вам ответил и своими словами, и предоставил первоисточник?
Также у вас есть чек-лист, и вы можете применить его к любой модификации и проверить её на совпадение.
Я развернуто ответил на ваш вопрос о всего одной выборке, захватив несколько смежных вариантов.
По планам запроса и таймингам можно понять, чего ждать от этого подхода и жизнеспособен ли он вообще. Если сделать статистически значимое количество тестов, то принципиально ничего не поменяется, или вы это будете оспаривать?
Не «не будет», а «не должна». На ваших наблюдениях на вашей СУБД на ваших данных вы этого не обнаружили, однако нет гарантии, что это всегда будет выполняться: как я уже писал, на моих наблюдениях оптимизатор запросов MS SQL как минимум единожды решил, что скан таблицы выгоднее, чем проход по индексу.
Хорошо, «не должна». Задача — оптимизировать запрос, а не охотиться на ведьм в лице full scan.
Может быть ситуация, когда в базе (в таблице) только книги, у которых реквизиты заполнены процентов на 20. При этом, вероятно, будет full scan и это правильно.
Давайте обратим наше внимание на этот казус и запомним его под звездочкой (*): когда мы поменяли условие выборки, нам понадобилось поменять отчет, чтобы производительность сохранилась. Иными словами, если у пользователя была настроенная удобная ему таблица, то в зависимости от того, по какому полю он производит фильтрацию, производительность системы радикально прыгает.
В любой базе данных с большим объемом запрос придется отлаживать: передвигать колонки или создавать индексы и переписывать JOINы.
К сожалению, заявление о «снижении риска» так и не подтверждено. Хуже того, у вас даже нет объективной метрики для этого самого риска (или хотя бы для деградации).
Я считаю, что передвигать колонки отчета, не вмешиваясь в архитектуру, проще и безопаснее. Вы считаете, что проще и безопаснее влезть в SQL Studio и понасоздавать там индексы.
Это дело вкуса, и, похоже, у нас разные представления о рисках.
Если вы хотите сказать, что у вас это можно сделать без change control, то вы показываете недостаток, а не достоинство вашей системы.
Что это?
У меня не нужно под каждый отчёт создавать индексы, в чем и есть суть.
Вы же предлагаете кликать в SSMS, значит, с политиками или без, вы рискуете накликать проблемы, и должны как минимум иметь доступ и разбираться в SSMS.
Это вы у себя дома в один клик. А в работающей системе вы сначала пройдете Change control и запланируете это в какой-то релиз.
То есть, кроме пользователя, которому это нужно, привлечете еще некоторое количество людей и времени.
Для специалиста? Давайте покажем специалисту, послушаем его.
Вы обвиняете в непрофессионализме людей и целые организации — ФИПС и канадскую компанию, проводившие патентный поиск и содействующие в составлении формулы. При этом вы же не стесняетесь заявить, что ничего не понимаете в патентном праве.
Хотя я, пожалуй, постою в сторонке в вашем споре с ними.
Я не про интерфейс говорю, а про содержание: значения полей Договор, Сумма, Предмет, Заказчик. Где у вас всё это?
Описание типов:
Объекты типов:
Вот она в чём проблема. Лично ваша проблема, которую вы проецируете на увиденное здесь.
Вы пробовали, результат вам не понравился, значит и у других получиться ничего путного не может. Знакомо.
Я тоже поделюсь. Когда в 1998 году я пришел инженером на автозавод после института и армии, я загорелся сделать бесконтактный прерыватель указателя поворотов. И тогда взрослый инженер, под полтос, сказал мне не тратить время. В качестве доказательства он привел похожий аргумент: я пробовал, не получилось. Транзисторы горят, у тиристоров большие потери… Но у меня в итоге получилось, хотя я применил пару решений, за которые был критикуем. Например, я запараллелил пару транзисторов, а у них разный коэффициент передачи, плавающие характеристики, ну и прочие в общем случае правильные вещи услышал я от коллег. Тем не менее, в том конкретном случае такое решение было оправдано и мне удалось пройти все испытания: наработку на отказ, климатику (исполнение УХЛ: от -45 до +55 С) и прочие. Даже тогда я не слушал старпёров, теперь и подавно.
Пример приведите, о чем речь, я его сделаю и продемонстрирую здесь.
Если ничего не нужно дорабатывать, давайте попробуем создать там такую схему данных и заполнить её:
Описание сущностей:
Экземпляры сущностей:
Редактор экземпляра:
Вот, например:
При принципиально идентичных структурах переносить ничего не нужно: вы просто обращаетесь к полям под другими именами в нужных таблицах и все. Грубо говоря, берем ядро Интеграла или Magento и переписываем одно под другое (переименовываем поля и таблицы).
Не получается? Значит структуры и подход разные.
Заработало? Там даже статическая картинка Договора не похожа на оригинал.
Возьмите простейший замусоленный здесь пример с книгами и авторами, загрузите в Magento и выполните серию запросов, которые здесь приведены. Сразу поймете, насколько далеки Magento и Интеграл в архитектурном плане.
Да, я об этом же и говорю. Конструктор. Мечта программиста.
Не забывайте, что мы делали поиск при неприменимом индексе в миллионе записей. Есть простые правила, которые лучше выполнять, пользуясь конструктором, и я показал, как это работает и к чему приводит.
Можно было их и не выполнять, ничего страшного не случится.
В 2003 году у нас было 13.5Тб в базе, и я многое понял тогда.
Это как если бы вы рассуждали, что поезд — это мотоцикл, потому что на колесах и ездит. Только нужно доработать немного.
Вот когда зададут и сделают, тогда и будет о чем говорить. Пока же эти пункты не выполняются.
Так пусть добавит, что же он раньше не добавлял?
Сначала подведите так, чтобы заработало.
Тип в названии таблицы — хардкод, не вяжется с описанием типа в таблице.
В простоте создания схемы данных и управления этими данными. В других моих статьях описано как это можно применять.
Скажем так, от гигабайта и до бесконечности.
Укажите хоть одну систему, удовлетворяющую опроснику. Прямо по всем пунктам. Не по названиям полей, а по принципу хранения мета-данных и данных.
Чек-лист сопровожден примечанием — должны выполняться 10 условий.
Имена полей не важны, важно их значение.
Я отрицал, что запатентована EAV. И сейчас придерживаюсь этого.
Тут всё не так просто. Но в целом, совершенно не важно что я вам тут отвечу. Есть документ, объективная реальность, не зависящая от комментариев о нем в интернете.
Как же я игнорирую, если я вам ответил и своими словами, и предоставил первоисточник?
Также у вас есть чек-лист, и вы можете применить его к любой модификации и проверить её на совпадение.
Отличается как раз уровнем риска. Сравните: «сделать неоптимальный запрос к базе» или «создать/удалить индекс в production системе».
По планам запроса и таймингам можно понять, чего ждать от этого подхода и жизнеспособен ли он вообще. Если сделать статистически значимое количество тестов, то принципиально ничего не поменяется, или вы это будете оспаривать?
Хорошо, «не должна». Задача — оптимизировать запрос, а не охотиться на ведьм в лице full scan.
Может быть ситуация, когда в базе (в таблице) только книги, у которых реквизиты заполнены процентов на 20. При этом, вероятно, будет full scan и это правильно.
В любой базе данных с большим объемом запрос придется отлаживать: передвигать колонки или создавать индексы и переписывать JOINы.
Я считаю, что передвигать колонки отчета, не вмешиваясь в архитектуру, проще и безопаснее. Вы считаете, что проще и безопаснее влезть в SQL Studio и понасоздавать там индексы.
Это дело вкуса, и, похоже, у нас разные представления о рисках.
Поверьте, вас это никоим образом не затронет, так что нет причин переживать.
У вас сейчас на руках столько же информации, сколько имею я.
Да, EAV в решении присутствует. Все на этом?
Что это?
У меня не нужно под каждый отчёт создавать индексы, в чем и есть суть.
Вы же предлагаете кликать в SSMS, значит, с политиками или без, вы рискуете накликать проблемы, и должны как минимум иметь доступ и разбираться в SSMS.
То есть, кроме пользователя, которому это нужно, привлечете еще некоторое количество людей и времени.