Осмелюсь заявить, что это вы не понимаете.
Чем отличается от EAV, EAV/CR, KV и иже с ними, я уже отчаялся объяснить.
Давайте так сформулирую: ни одно существующее ныне решение не будет ущемлено этим патентом. Просто потому что они с ним не конфликтуют.
Годится?
Система — это не только структура.
Даже структуру многие комментаторы здесь трактуют неверно, редуцированно. Систему же в целом они совсем отказываются понимать.
Данные можно преобразовать к тому виду, в котором они хранятся, чтобы использовать индекс.
Затруднение вызывает только применение индекса к диапазону чисел, потому что у них различается порядок — нельзя ранжировать по первым цифрам, нужно считать всё число.
Я правда не разбираюсь в патентах, но в обратном случае в существовании патентов не было бы смысла.
Дело не в незнании вами патентных тонкостей, а в небрежном отношении к материалу. Вы приводите часть некоей структуры, которую никак нельзя трансформировать в мою обратимыми преобразованиями (перестановка полей, транспонирование таблиц, декомпозиция и объединение и т.д.).
То есть, то, что вы привели, вообще никакого отношения не имеет к обсуждаемой здесь статье.
И здесь вы всё переврали, не повторив таблицу из 5 полей с 3 индексами. Но в этот раз ваш косяк виден как на ладони.
Главная вещь, которую стоит уяснить: в при приведенном здесь подходе полный скан таблицы не случится никогда.
Я тоже сделал табличку с 1048552 книгами (сколько влезло на лист экселя) и 142654 авторами.
Книги:
Авторы:
Также я сделал отчет, но не писал SQL, а набрал нужные поля и сразу вписал условие (перебрал их несколько, пока не получил не менее 300 и не более 1000 результатов):
Последнее условие вернуло такой результат — 465 строк с авторами по маске, к которой неприменим индекс:
Все запросы при построении отчета, а их было 6 штук (проверка токена пользователя, поиск отчета, сбор метаданных, выполнение отчета), выполнились за 124.3 мс, из которых 121.3 мс заняло выполнение собственно запроса для отчета.
Сам запрос получился такой:
SELECT a225.val v1_225,a217.val v2_217,a223.val v3_217,a219.val v4_217
FROM test a225
LEFT JOIN (test r217 JOIN test a217 USE INDEX (PRIMARY)) ON r217.up=a217.id AND a225.id=r217.t AND a217.t=217
LEFT JOIN test a223 ON a223.up=a217.id AND a223.t=223
LEFT JOIN test a219 ON a219.up=a217.id AND a219.t=219
WHERE a225.up!=0 AND length(a225.val) AND a225.t=225 AND a225.val LIKE '%aro%'
Примерно такой запрос, как ниже.
Количество записей на странице определяется параметром отчета, номер страницы передается также параметром.
SELECT a330.val v1837447_321,a208.val v1837452_0,a236.val v1837453_208,a260.val v1837454_208,a261.val v1837455_208,a210.val v1837456_0
FROM hr4hr a209
LEFT JOIN (hr4hr r321 JOIN hr4hr a321 ) ON r321.up=a209.id AND a321.id=r321.t AND a321.t=321
LEFT JOIN hr4hr a330 ON a330.up=a321.id AND a330.t=330 LEFT JOIN hr4hr a208 ON a208.t=208 AND a209.up=a208.id
LEFT JOIN (hr4hr r236 JOIN hr4hr a236 USE INDEX (PRIMARY)) ON r236.up=a208.id AND a236.id=r236.t AND a236.t=234
LEFT JOIN hr4hr a260 ON a260.up=a208.id AND a260.t=260
LEFT JOIN hr4hr a261 ON a261.up=a208.id AND a261.t=261
LEFT JOIN hr4hr a210 ON a210.t=210 AND a208.up=a210.id
WHERE a209.up!=0 AND a209.val!='' AND a209.t=209 AND a330.val ='Иванов'
LIMIT 10,20
Запрограммированный отчет в интерфейсе будет выглядеть примерно так:
В базу улетит примерно такой запрос:
SELECT a227.val v1_217,COUNT(a217.val) v2_217
FROM test a217
LEFT JOIN (test r227 JOIN test a227) ON r227.up=a217.id AND a227.id=r227.t AND a227.t=225
WHERE a217.up!=0 AND a217.t=217
GROUP BY v1_217
HAVING v2_217>=99999999 AND v2_217<=2
Как это делается можно также посмотреть на видео (полторы минуты).
прикрутив к ней зачем то еще дополнительное поле типа
Как вы можете рассуждать, не понимая о чем речь?
По одной из ссылок вообще информация из одного из ближайших патентов 1994 года, вы это знали?
Только там кусок решения для частного случая, у меня же — целое, законченное решение.
В данном случае нет цели хранения древовидных структур, хотя это тоже можно эмулировать, если будет задача.
Повторюсь в очередной раз, система решает задачу РСУБД в общем, без экзотики и спецнаправлений.
По существу: по таймингу или плану запроса есть замечиния?
Иначе слив засчитан.
Чем отличается от EAV, EAV/CR, KV и иже с ними, я уже отчаялся объяснить.
Давайте так сформулирую: ни одно существующее ныне решение не будет ущемлено этим патентом. Просто потому что они с ним не конфликтуют.
Годится?
Даже структуру многие комментаторы здесь трактуют неверно, редуцированно. Систему же в целом они совсем отказываются понимать.
Структуру данных запатентовать нельзя, во всяком случае в РФ.
Это я к тому, что вы не разобрались в сути статьи.
Нужен алгоритм, который строит запросы и прорисовывает интерфейс.
Вот этот интерфейс (ссылка с ролью админа):
https://tryint.ru/index.php?db=test&secret=0t1e2s3t4
Затруднение вызывает только применение индекса к диапазону чисел, потому что у них различается порядок — нельзя ранжировать по первым цифрам, нужно считать всё число.
Дело не в незнании вами патентных тонкостей, а в небрежном отношении к материалу. Вы приводите часть некоей структуры, которую никак нельзя трансформировать в мою обратимыми преобразованиями (перестановка полей, транспонирование таблиц, декомпозиция и объединение и т.д.).
То есть, то, что вы привели, вообще никакого отношения не имеет к обсуждаемой здесь статье.
Главная вещь, которую стоит уяснить: в при приведенном здесь подходе полный скан таблицы не случится никогда.
Я тоже сделал табличку с 1048552 книгами (сколько влезло на лист экселя) и 142654 авторами.
Книги:
Авторы:
Также я сделал отчет, но не писал SQL, а набрал нужные поля и сразу вписал условие (перебрал их несколько, пока не получил не менее 300 и не более 1000 результатов):
Последнее условие вернуло такой результат — 465 строк с авторами по маске, к которой неприменим индекс:
Все запросы при построении отчета, а их было 6 штук (проверка токена пользователя, поиск отчета, сбор метаданных, выполнение отчета), выполнились за 124.3 мс, из которых 121.3 мс заняло выполнение собственно запроса для отчета.
Сам запрос получился такой:
План его выполнения:
Количество записей на странице определяется параметром отчета, номер страницы передается также параметром.
Хотя это всё вообще не важно.
Запрограммированный отчет в интерфейсе будет выглядеть примерно так:
В базу улетит примерно такой запрос:
Как это делается можно также посмотреть на видео (полторы минуты).
Систему хранения и способ обработки.
Как вы можете рассуждать, не понимая о чем речь?
По одной из ссылок вообще информация из одного из ближайших патентов 1994 года, вы это знали?
Только там кусок решения для частного случая, у меня же — целое, законченное решение.
Повторюсь в очередной раз, система решает задачу РСУБД в общем, без экзотики и спецнаправлений.
Это решение эмулирует РСУБД и её возможности.