Не понятна новизна решения. Принципиальных отличий от EVA нет. Подобная идея скорее всего приходила в голову не один раз каждому архитектору и продвинутому разработчику.
Это не таблица, это выборка из таблиц.
Трансформация структуры — это когда… конечная структура содержит всю информацию для однозначного обратного преобразования.
Если мне заплатят, то я могу все таблицы Magento с их данными свести к одному Adjacency List, который будет содержать всю информацию для
однозначного обратного преобразования
Точно также как и привести ее к вашей структуре (которая является разновидностью Adjacency List) с возможностью обратной трансформации. Означает ли это, что Magento нарушает ваш патент?
Т.е. если кому-то понадобится использовать в своем ПО таблицу аналогичную вашей
из 5 полей: ID, родитель (ID), тип (тоже ID), порядок среди равных (число), значение (набор байтов)
и все, автоматически вытекающие из этой структуры варианты запросов к этой таблице — он не нарушит ваш патент?
Ели нет — то зачем тогда это нужно было патентовать?
Вы приводите часть некоей структуры, которую никак нельзя трансформировать в мою обратимыми преобразованиями (перестановка полей, транспонирование таблиц, декомпозиция и объединение и т.д.).
Еще раз, выше я писал, что парой-тройкой джоинов можно трансформировать практически любое EAV хранилище к вашей структуре.
Вот для примера код для Magento:
SELECT
`product`.`entity_id` AS `ID`,
`parent_id` AS `Parent ID`,
`entity_int`.`attribute_id` AS `Type ID`,
`sort_order` AS `Order`,
`value` AS `Value`
FROM
catalog_product_entity AS `product`
JOIN catalog_product_relation AS `relation`
ON product.entity_id = relation.child_id
JOIN catalog_product_entity_int AS `entity_int`
ON product.entity_id = entity_int.entity_id
JOIN eav_entity_attribute as `attribute`
ON entity_int.attribute_id = attribute.attribute_id
Он выбирает `ID`всех простых товаров, которые входят по `Parent ID` в составные товары, для каждого `ID` выбирается тип целочисленного атрибута `Type ID` отсортированный по порядку аттрибутов `Order` со значением `Value`, на выходе получаем что-то вроде такого:
Чем эта таблица отличается от вашей?
Даже еще хуже, после первого выстрела у вас уже не играют две каморы, т.к. мы знаем что патроны заряжены последовательно. Т.е. шанс быть убитым без прокрутки — 1/2, а с прокруткой — 1/3, т.е. надо крутить, чтобы шанс выжить был выше.
Если стрелять второй раз, то у вас уже не играет пустая камора барабана, выпавшая в первый раз. Т.е. у вас играют два патрона в пяти каморах. А если крутануть барабан, то у вас играет еще раз эта же пустая камора, т.е. у вас снова два патрона в шести каморах. Вероятность быть убитым без прокрутки 2/5, с прокруткой 2/6, т.е. с прокруткой вероятность быть убитым — меньше.
Вы приводите часть некоей структуры, которую никак нельзя трансформировать в мою обратимыми преобразованиями (перестановка полей, транспонирование таблиц, декомпозиция и объединение и т.д.).
Да вот как раз можно, просто в Magento (да и в любой другой аналогичной системе) информация разделана на несколько таблиц из которых парой-тройкой джоинов можно получить вашу таблицу.
Еще раз повторюсь, вы запатентовали вполне себе очевидную, я бы даже сказал — тривиальную структуру данных.
Скорее всего это сделано чтобы не перегружать схему. Видимо автор хотел показать только зависимость по типу атрибута. Я конечно не художник, но с entity_id будет выглядеть как-то так:
Человек заново «изобрел» adjacency list model (очевидно не подозревая о ее существовании) прикрутив к ней зачем то еще дополнительное поле типа. Более того он утверждает, что
не используются триггеры и constraints, просто потому что всё это до сих пор не понадобилось
при этом не объясняя как ему удается сохранять консистентность хранимых данных и не терять ресурсы и производительность на рекурсивных запросах.
Я думаю это просто следствие того, что он не знает про limitations of the adjacency list model.
UltimaSol пожалуйста, прежде чем патентовать что-то — прочтите для общего развития хотя бы вот эту простую статью из топа гуглопоиска по данной теме.
Если не можете читать на английском — хабр вам в помощь.
Вон например люди еще в 2012 году в статье и обсуждении размышляли как можно улучшить Adjacency List (что-то вроде ваших типов в отдельной таблице), но им даже в голову не пришло патентовать очевидные вещи!
Если кто-то сможет его с этими характеристиками написать.
UltimaSol переизобрел структуру таблицы для хранения дерева данных объектов произвольной глубины, кстати уже неоднократно описанную во многих учебниках и статьях по БД.
Как я написал тут он просто не понимает насколько эта, на первый взгляд, компактная и простая структура хранения данных будет «дорога» при работе с ней на реальных объектах, для которых она действительно может потребоваться (потому что для большинства случаев она просто не нужна).
Вы хоть понимаете о чем речь?
Где в этом сервисе объекты произвольной глубины?
Как вы их ищете по атрибуту, который может быть на ЛЮБОМ уровне в ЛЮБОЙ ветке дерева данных такого объекта?
Как вы в конце концов извлекаете и собираете такие объекты, где чтения данных КАЖДОГО уровня КАЖДОЙ ветки требуется ОТДЕЛЬНЫЙ запрос к БД?
там нет оптимизации для выборки объектов произвольной глубины
Уверен что UltimaSol даже не представляет как это его «изобретение» будет жрать как не в себя ресурсы и жутко тормозить на т.н. рекурсивных запросах к этой единственной таблице если таких объектов произвольной глубины будет в ней достаточно много. Думаю уже ста тысяч хватит чтобы все просто умерло даже на самом крутом железе.
Поздравляю всех! «Стену» таки вернули.
Отдельная благодарность за это автору, я думаю этот скрипт сыграл немаловажную роль в принятии решения о возвращении всех ресурсов хабра на один домен.
Вы занимаетесь передергиванием. Знать, что кота лучше не засовывать в микроволновку != знать о том, как работает браузер и что, например, гуглы-фейсбуки могут быть в курсе о всех ваших действиях на сторонних сайтах, если на этих сайтах стоят их скрипты.
Я передергиваю не больше чем вы. Основную часть трэкеров и рекламы на том же хабре и еще 99+% сайтов могут обрезать пара-тройка расширений для браузера, например ABP+Ghostery. Для их установки и настройки никаких особых знаний не нужно и спрашивать разрешения у хабра тоже. Но вот почему-то у 99+% людей они не установлены.
Как я уже комментировал в прошлой статье, но так и не дождался ответа от UltimaSol:
Достаточно погуглить по create table parent_id type_id и вы найдете кучу решений использующих этот подход задолго до вас! Он настолько очевиден, что люди даже используют такие же имена полей — вот парочка ссылок с первой же страницы поиска:
2013 CREATE TABLE myproducts (uid, parent_id, type_id, name ...
2007 CREATE TABLE menu_menuitem (id, parent_id, type_id, order, title ...
2013 CREATE TABLE myproducts (uid, parent_id, type_id, name ...
2007 CREATE TABLE menu_menuitem (id, parent_id, type_id, order, title
Ели нет — то зачем тогда это нужно было патентовать?
Вот для примера код для Magento:
Он выбирает `ID`всех простых товаров, которые входят по `Parent ID` в составные товары, для каждого `ID` выбирается тип целочисленного атрибута `Type ID` отсортированный по порядку аттрибутов `Order` со значением `Value`, на выходе получаем что-то вроде такого:
Чем эта таблица отличается от вашей?
Еще раз повторюсь, вы запатентовали вполне себе очевидную, я бы даже сказал — тривиальную структуру данных.
Последний вопрос к UltimaSol:
Правильно ли я понимаю что вы запатентовали структуру данных?
Я думаю это просто следствие того, что он не знает про limitations of the adjacency list model.
UltimaSol пожалуйста, прежде чем патентовать что-то — прочтите для общего развития хотя бы вот эту простую статью из топа гуглопоиска по данной теме.
Если не можете читать на английском — хабр вам в помощь.
Вон например люди еще в 2012 году в статье и обсуждении размышляли как можно улучшить Adjacency List (что-то вроде ваших типов в отдельной таблице), но им даже в голову не пришло патентовать очевидные вещи!
Как я написал тут он просто не понимает насколько эта, на первый взгляд, компактная и простая структура хранения данных будет «дорога» при работе с ней на реальных объектах, для которых она действительно может потребоваться (потому что для большинства случаев она просто не нужна).
Где в этом сервисе объекты произвольной глубины?
Как вы их ищете по атрибуту, который может быть на ЛЮБОМ уровне в ЛЮБОЙ ветке дерева данных такого объекта?
Как вы в конце концов извлекаете и собираете такие объекты, где чтения данных КАЖДОГО уровня КАЖДОЙ ветки требуется ОТДЕЛЬНЫЙ запрос к БД?
Отдельная благодарность за это автору, я думаю этот скрипт сыграл немаловажную роль в принятии решения о возвращении всех ресурсов хабра на один домен.