но вы правы потолок настает в N раз быстрее, где N — среднее число параметров у сущности, но если у вас не милионы таких сущностей, а сотни тысяч, то можно не париться
вот о сравнении не скажу, потому что мне нужно было именно это решение, потому как я плохо заранее представлял хранимые сущности, а не из за выигрыша в скорости. Но думаю что если вы заранее знаете поля, которые используются в поиске, то на широкой таблице и суммарном индексе можно получить существенный выигрыш, но я не знал ни популярных полей для поиска, ни собственно изначально полного их списка.
тесты конечно скриптами внешними. Ну как я описал генератор SQL был, но время генерации SQL ничтожно. 0.2 сек это при обширных запросах, когда в реззультате слишком много записей получается + какой-нибудь group by.
если же у вас ограничения по поиску выделяют всего 1/100 или даже 1/20 таблицы, то все летает ибо используется праймари индекс
На МуSQL я тестировал на таблице в 200 000 сущностей, по 40 параметров у каждой случайным образом заданных. поиск по любой комбинации параметров производится в пределах 0.0001-0.2 сек
в общем то у меня в сутки происходит заливка 10к новых обектов, а вся база крутится на предмет поиска и все летает. вы совершенно верно подметили, что производительность на уровне.
=) уж тебе ли не знать, сколько времени я отвожу проектированию?
вот видно — не внимательно читал:
>а практике, при решении подобных задач всегда находится набор свойств…
они попадают/качуют в первичные, написано же:
«выделить первичные (наиболее используемые в поиске) и вторичные свойства сущности, по первичным свойствам создаем таблицу»
еще раз повторюсь: если ты например осваиваешь новый рынок, то не знаешь какое поле будет наиболее употребительно для поиска.
второе: уневивирсальное решение — хороший метод для анализа.
вот сделаешь ты мега читаемую таблицу на 40 столбцов, а окажется она заполена на 20%, будут ли у тебя индексы работать? нет.
Entity-Attribute-Value, Сущность-атрибут-значение (EAV)
если же у вас ограничения по поиску выделяют всего 1/100 или даже 1/20 таблицы, то все летает ибо используется праймари индекс
вот видно — не внимательно читал:
>а практике, при решении подобных задач всегда находится набор свойств…
они попадают/качуют в первичные, написано же:
«выделить первичные (наиболее используемые в поиске) и вторичные свойства сущности, по первичным свойствам создаем таблицу»
еще раз повторюсь: если ты например осваиваешь новый рынок, то не знаешь какое поле будет наиболее употребительно для поиска.
второе: уневивирсальное решение — хороший метод для анализа.
вот сделаешь ты мега читаемую таблицу на 40 столбцов, а окажется она заполена на 20%, будут ли у тебя индексы работать? нет.