Какими именно?
Что конструктор имеет накладные расходы и в простейших случаях производительность ниже, я заявляю на иллюстрации и в самой статье.
Тексты и планы всех-всех запросов нужны?
Про метрики нет смысла разводить холивар. Вы велели провести сравнение тайминга и запросов, я это сделал. Про метрики рисков нужна отдельная статья.
А вот теперь давайте вернемся к отмеченной выше звездочки, и вспомним, что чтобы избежать падения производительности на конкретном запросе, автору пришлось этот запрос перестроить. Так чем же одна подстройка отличается от другой?
На это я косвенно отвечал в другом комментарии, что создание индекса в базе после ковыряния в профайлере дороже обходится, чем передвинуть одним кликом колонку отчета.
При этом специально взят запрос по неиндексируемому значению. В более простом и привычном случае порядок колонок не важен, как в примере с КЛАДРом, где поиск идет по любому полю из восьми возможных.
Раз уж я разобрался в вашей системе, скажу пару слов в защиту. Умудриться засунуть все в одну таблицу это конечно интересное инженерное решение, но новизны в нем нет. Просто так никто не делает по причинам производительности.
Вот и славно. Никто так не делает, как вы сами подтвердили.
А вся разница как раз в этом:
Индекс логически как бы разбивает строки на под-таблицы, но технически это обычное ускорение выборки по условию.
Если расширять признаки на несколько таблиц, то получаются аналоги существующих систем.
Вот здесь я не согласен, покуда типы не хранятся в таблице единой структуры, а хардкодятся в запросах — это уже не аналоги.
Также есть нестандартная обработка ссылок, но технически это «костыль» — значение хранится в поле с другой семантикой и специальным образом обрабатывается.
В чем проблема с семантикой? В любом случае ссылка делается по ID, а его запись всегда является типом.
«костыль» — это StoreID в Magento, если я правильно понимаю это как ID магазина. Вот это действительно адский ад.
Проблема в том, что вы заявляете что ничего подобного не существует и рассматриваете неопределенный круг модификаций.
Доказать вашу правоту очень просто: берете опросник, любой аналог и за 5 минут кровавого копи/пейста показываете идентичность.
Почему не выполняется? Индекс в системе на аналогичных полях есть? Есть. В этих таблицах могут хранится значения атрибутов? Могут.
В комментарии выше я начал проводить проверку по шагам, и это очень просто: берете кусок скрипта или запроса и вставляете в качестве подтверждения.
По второму же пункту вы предлагаете собирать скрипты разных таблиц, которые используются по разному. Ведь это не отдельные системы, а куски систем, которые действительно идентичны в сотнях систем структурно и используются похоже.
Одна система — один проход опросника.
Понятно, можно из кусочков насобирать: там один индекс берём, тут другой, из 2010 года тащим какой-то справочник. Только это не единая система, а набор кусочков, которые вместе не то что не обеспечат производительность, о которой я тут заявляю, а даже работать нормально не смогут вместе, без соответствующих доработок.
Даже первые два пункта не пройдены: нет ссылки на систему, нет её структуры, нет её индексов. О чем говорить?
И это мы еще не добрались, что в этой системе описаны типы, используемые для создания других типов и их реквизитов, которые описывают наборы связанных данных (связанных как раз через ссылки на тип или объект).
Знаю. Стоит у меня на компьютере. Там добавлен индекс на «Type ID + Value». По аналогии с другими таблицами.
Для экспериментального подтверждения соответствия Magento системе из этой статьи предлагаю вам догрузить оставшиеся миллион двести записей и прогнать запросы, которые обсуждаются в статье, штатными средствами Magento.
Должно работать, если подход и структура идентичны.
Такой индекс есть в других таблицах, я об этом писал.
Давайте вставим данные в другую таблицу и проверим еще раз опросником. Иначе условие не выполняется.
Во-первых, с учетом предыдущего пункта выполняется. Во-вторых, получается, что наличие патента запрещает создать такой индекс, так как это единственное отличие. Или другими словами, идея создать индекс является частью патента.
Это не единственное отличие, а первое встретившееся на втором шаге из 10. Найдите систему, где этот индекс был добавлен хотя бы до публикации этой статьи, и мы проверим оставшиеся пункты (не забыв перепроверить и первые два).
Даже если его нет в какой-то из таблиц, его может создать тот, что занимается поддержкой установленной системы, и кто вообще не в курсе про ваш патент.
Да, может. Это был я, например. Только я еще выкинул всё остальное ненужное и добавил что-то от себя. Получился совсем другой продукт.
Дело в том, что только добавление этого индекса ничего принципиально не решит и не является единственным отличием.
Как IT-специалист считаю, что в текущем виде патент охватывает множество существующих систем.
Спасибо! Вы проделали большую работу, но давайте её закончим, прежде чем делать вывод. Вы поместили данные в таблицу и они даже отображаются в интерфейсе. Ок, но я вижу, что чтобы сделать из этого Интеграл, придется доработать Magento.
Пойдемте прямо по порядку, по пунктам:
1. Все данные хранятся в одной таблице (см. также п.3.), содержащей как минимум следующие поля: ID, Parent ID, Type ID, Value
2. Для таблицы построены как минимум следующие индексы: ID; Type ID + Value; Parent ID + Type ID.
ID есть, это PRIMARY KEY (`value_id`)
Type ID + Value — не вижу
Parent ID + Type ID есть, это
UNIQUE INDEX `CATALOG_PRODUCT_ENTITY_VARCHAR_ENTITY_ID_ATTRIBUTE_ID_STORE_ID` (`entity_id`, `attribute_id`, `store_id`)
Второй пункт не выполняется, что означает, что Magento как есть не конфликтует с патентом и не входит в упомянутое вами «множество существующих систем».
Если вы знаете какую-то реализацию Magento или нечто поверх неё, где этот индекс добавлен, то будет шанс, что и остальные пункты опросника тоже выполнятся. Давайте на них посмотрим.
Впрочем, это не важно. Меня больше интересовало то, что хотя ваш конструктор и имеет поддержку иерархических структур (благодаря id — parent_id), он при этом для них не оптимизирован (поэтому нельзя, скажем, сделать такое дерево категорий, где категории будут вложенными объектами).
Не было задачи поддержки иерархических структур в вашем понимании. Тем не менее, бизнес-задачу я вам выполнил.
Более того, поддержки ссылочной целостности тоже нет.
И что же происходит с производительностью за ~900 байтами кода?
Вы не меньше трех раз пытались склонить меня всерьез рассматривать варианты с полем длиной более 900 байт, индексируемым полностью.
Вероятно, вы даже делали какие-то решения, где код номенклатуры превышает эту длину, наверное, вот это одно из них, а здесь вы косвенно на него же намекаете.
Это недостижимое ограничение в нормально спроектированной системе, потому что есть масса способов избежать полного индексирования таких полей, и особенно идентифицирующих полей.
Как я уже комментировал в прошлой статье, но так и не дождался ответа
Вы получили ответ в виде опросника, по которому вы можете проверить все решения по вашей ссылке и убедиться, что ни одно из них не соответствует полностью тому, о чем статья.
В этом конструкторе реализуем любой запрос, возможный в реляционной базе данных, кроме рекурсии (пока). Я так заявлял в самом начале и сейчас вам напоминаю.
Причем тут DDD и ДОБД?
(название, конечно, то ещё)
Не соскакивайте с обсуждения изначальной вашей же задачи.
Задача с подвохом?
Самый очевидный способ: хранить в коде иерархии весь путь наверх. Это компактно и быстро. Нужен один запрос на выборку. Также одним запросом делается изменение положения в иерархии, если, например, перенесли категорию в другое подчинение.
Уточню на всякий случай: вы тычете в любую категорию, и та раскрывается вниз до самых низших элементов, и при этом нужно выполнить только один запрос. Так?
Или же количество запросов может быть больше одного, ибо
Я пока показал здесь два примера: специализации в рекрутерском приложении и иерархия КЛАДР на стенде. Но там уровни фиксированные, а вы, вероятно, ждете нечто динамическое и неограниченной глубины.
Давайте рассмотрим на примере — предложите его.
Что конструктор имеет накладные расходы и в простейших случаях производительность ниже, я заявляю на иллюстрации и в самой статье.
Тексты и планы всех-всех запросов нужны?
Про метрики нет смысла разводить холивар. Вы велели провести сравнение тайминга и запросов, я это сделал. Про метрики рисков нужна отдельная статья.
На это я косвенно отвечал в другом комментарии, что создание индекса в базе после ковыряния в профайлере дороже обходится, чем передвинуть одним кликом колонку отчета.
При этом специально взят запрос по неиндексируемому значению. В более простом и привычном случае порядок колонок не важен, как в примере с КЛАДРом, где поиск идет по любому полю из восьми возможных.
Вот и славно. Никто так не делает, как вы сами подтвердили.
А вся разница как раз в этом:
Вот здесь я не согласен, покуда типы не хранятся в таблице единой структуры, а хардкодятся в запросах — это уже не аналоги.
В чем проблема с семантикой? В любом случае ссылка делается по ID, а его запись всегда является типом.
«костыль» — это StoreID в Magento, если я правильно понимаю это как ID магазина. Вот это действительно адский ад.
Доказать вашу правоту очень просто: берете опросник, любой аналог и за 5 минут кровавого копи/пейста показываете идентичность.
В комментарии выше я начал проводить проверку по шагам, и это очень просто: берете кусок скрипта или запроса и вставляете в качестве подтверждения.
По второму же пункту вы предлагаете собирать скрипты разных таблиц, которые используются по разному. Ведь это не отдельные системы, а куски систем, которые действительно идентичны в сотнях систем структурно и используются похоже.
Одна система — один проход опросника.
Понятно, можно из кусочков насобирать: там один индекс берём, тут другой, из 2010 года тащим какой-то справочник. Только это не единая система, а набор кусочков, которые вместе не то что не обеспечат производительность, о которой я тут заявляю, а даже работать нормально не смогут вместе, без соответствующих доработок.
Даже первые два пункта не пройдены: нет ссылки на систему, нет её структуры, нет её индексов. О чем говорить?
И это мы еще не добрались, что в этой системе описаны типы, используемые для создания других типов и их реквизитов, которые описывают наборы связанных данных (связанных как раз через ссылки на тип или объект).
Для экспериментального подтверждения соответствия Magento системе из этой статьи предлагаю вам догрузить оставшиеся миллион двести записей и прогнать запросы, которые обсуждаются в статье, штатными средствами Magento.
Должно работать, если подход и структура идентичны.
Давайте вставим данные в другую таблицу и проверим еще раз опросником. Иначе условие не выполняется.
Это не единственное отличие, а первое встретившееся на втором шаге из 10. Найдите систему, где этот индекс был добавлен хотя бы до публикации этой статьи, и мы проверим оставшиеся пункты (не забыв перепроверить и первые два).
Да, может. Это был я, например. Только я еще выкинул всё остальное ненужное и добавил что-то от себя. Получился совсем другой продукт.
Дело в том, что только добавление этого индекса ничего принципиально не решит и не является единственным отличием.
Давайте возьмем решение как есть, выберем одну таблицу и на ней всё проверим.
Иначе получается «здесь читать, а там не читать».
Вот на это я хочу ответить развернуто. Укажите, пожалуйста, какой минимальный объем можно уже считать большим?
Спасибо! Вы проделали большую работу, но давайте её закончим, прежде чем делать вывод. Вы поместили данные в таблицу и они даже отображаются в интерфейсе. Ок, но я вижу, что чтобы сделать из этого Интеграл, придется доработать Magento.
Пойдемте прямо по порядку, по пунктам:
`value_id` INT(11) NOT NULL AUTO_INCREMENT COMMENT 'Value ID',
`attribute_id` SMALLINT(5) UNSIGNED NOT NULL DEFAULT '0' COMMENT 'Attribute ID',
`store_id` SMALLINT(5) UNSIGNED NOT NULL DEFAULT '0' COMMENT 'Store ID',
`entity_id` INT(10) UNSIGNED NOT NULL DEFAULT '0' COMMENT 'Entity ID',
`value` VARCHAR(255) NULL DEFAULT NULL COMMENT 'Value')
ID есть, это PRIMARY KEY (`value_id`)
Type ID + Value — не вижу
Parent ID + Type ID есть, это
UNIQUE INDEX `CATALOG_PRODUCT_ENTITY_VARCHAR_ENTITY_ID_ATTRIBUTE_ID_STORE_ID` (`entity_id`, `attribute_id`, `store_id`)
Второй пункт не выполняется, что означает, что Magento как есть не конфликтует с патентом и не входит в упомянутое вами «множество существующих систем».
Если вы знаете какую-то реализацию Magento или нечто поверх неё, где этот индекс добавлен, то будет шанс, что и остальные пункты опросника тоже выполнятся. Давайте на них посмотрим.
Не было задачи поддержки иерархических структур в вашем понимании. Тем не менее, бизнес-задачу я вам выполнил.
Кто вам такое сказал?
В общем случае применяется предложенный конструктор, а вот реализация конкретных решений придумывается исходя из параметров конкретной задачи.
У номенклатуры нет 1000 уровней, а если будет, то будет выбрано иное решение. Поэтому я и просил конкретный пример.
Вы не меньше трех раз пытались склонить меня всерьез рассматривать варианты с полем длиной более 900 байт, индексируемым полностью.
Вероятно, вы даже делали какие-то решения, где код номенклатуры превышает эту длину, наверное, вот это одно из них, а здесь вы косвенно на него же намекаете.
Это недостижимое ограничение в нормально спроектированной системе, потому что есть масса способов избежать полного индексирования таких полей, и особенно идентифицирующих полей.
Вы получили ответ в виде опросника, по которому вы можете проверить все решения по вашей ссылке и убедиться, что ни одно из них не соответствует полностью тому, о чем статья.
Вы брались дважды за это, как же вам не понять?
Не запросом, а только фильтром имя=значение фильтра
В каком смысле? Поле код не ограничено по длине, значит и вложенность тоже.
Причем тут DDD и ДОБД?
(название, конечно, то ещё)
Не соскакивайте с обсуждения изначальной вашей же задачи.
Вообще-то, применял.
Что я тут программировал? Собрал ссылку для интерфейса?
Без проблем.
Но вы сначала главное скажите: дана задача, она выполнена. Подтверждаете?
Не понял. Есть код и есть название, это два атрибута, как ни крутите.
Вот, написал, руками. Не ногами же.
Запрос:
Отчет:
Самый очевидный способ: хранить в коде иерархии весь путь наверх. Это компактно и быстро. Нужен один запрос на выборку. Также одним запросом делается изменение положения в иерархии, если, например, перенесли категорию в другое подчинение.
Или же количество запросов может быть больше одного, ибо
Давайте рассмотрим на примере — предложите его.