вот о сравнении не скажу, потому что мне нужно было именно это решение, потому как я плохо заранее представлял хранимые сущности, а не из за выигрыша в скорости. Но думаю что если вы заранее знаете поля, которые используются в поиске, то на широкой таблице и суммарном индексе можно получить существенный выигрыш, но я не знал ни популярных полей для поиска, ни собственно изначально полного их списка.
тесты конечно скриптами внешними. Ну как я описал генератор SQL был, но время генерации SQL ничтожно. 0.2 сек это при обширных запросах, когда в реззультате слишком много записей получается + какой-нибудь group by.
если же у вас ограничения по поиску выделяют всего 1/100 или даже 1/20 таблицы, то все летает ибо используется праймари индекс
На МуSQL я тестировал на таблице в 200 000 сущностей, по 40 параметров у каждой случайным образом заданных. поиск по любой комбинации параметров производится в пределах 0.0001-0.2 сек
в общем то у меня в сутки происходит заливка 10к новых обектов, а вся база крутится на предмет поиска и все летает. вы совершенно верно подметили, что производительность на уровне.
=) уж тебе ли не знать, сколько времени я отвожу проектированию?
вот видно — не внимательно читал:
>а практике, при решении подобных задач всегда находится набор свойств…
они попадают/качуют в первичные, написано же:
«выделить первичные (наиболее используемые в поиске) и вторичные свойства сущности, по первичным свойствам создаем таблицу»
еще раз повторюсь: если ты например осваиваешь новый рынок, то не знаешь какое поле будет наиболее употребительно для поиска.
второе: уневивирсальное решение — хороший метод для анализа.
вот сделаешь ты мега читаемую таблицу на 40 столбцов, а окажется она заполена на 20%, будут ли у тебя индексы работать? нет.
а вы пытаетесь применить метод к не той проблеме. Вот посмотрите мою задачу (80к автомобилей, 47 параметров) и вы поймете, преимущества.
а кстати у вас все ограничения в таблицу класть. id нименования, поле, возможные переходы.
а вот я против сравнительного анализа в одной статье. Ибо как писал ниже: выбирать все равно вы будите и вы сами можете прочесть одно, прочесть другое и решить себе. Я ж не нанимался репортером чтоб все писать. и денег я з аэто не получу, а так просто делаю доброе дело — рассказываю чтоб и критику послушать и просто провести вечер в форуме.
так вот вы усложняете не меньше чем я. Общие свойства в одном месте. а другие в другом. а теперь просто представьте что у вас оказалось что поле цвет было частным, а стало общим. Как вы будите вводить изменение. внизу правильно сказали, что если сущностей не много и не предполагается «гуляние» структуры, то пользуйтесь обычным классическим решением, вот я знал заранее что параметров много, какие то будут удалены, какие-то добавлены и не ясно какие самые популярные для поиска
вот я напишу, а вы не поверите опять…
ваш SELECT * FROM oil будет использовать максимум один индекс, а значит если в базе 1024 товаров, из них половина в price < 30, и 1/4 в AND type in ('Castrol','Mobile'), то будет использован индекс на поле type (у вас ведь нет индекса на price+type) собственно выделив 1/4 вы дальше по базе результату пойдете простым перебором.
в случае полной нормализации ВСЕ ждойны происходят с оператором on, который задает связь по первичному ключу + если весит индекс на value то поиск по всем полям будет вестись по бинарному дереву ибо на все эти джойны будут наложен один индекс а не несколько.
а ведь есть и поля которые чисто технические (кол-во на складе) и тогда запрос: все товары, которых менее 100 на складе и размером не более 100см будут у вас бегать по разным таблицам и гемору вы отгребете не менее чем на написание конструктора SQL запроса (что я сделал за вас)
вот 5 человек заминусовало топик… Зачем спрашивается? что тут плохого именно? бывают топики какие-то хорошие — им плюс ставят, бывают плохие — им минус ставят. Ну ставишь минус — утруди себя работой объясни, а тупо пробигая "-" лепи. Такое ощушение что все индусы, которые не врубаются лепят минусы
неправильно вы думаете. Да и говорите вы неверно: Во первых если вы заранее не знаете по каким полям будет идти поиск, то вы не только проиграете по скорости с таблицей в 30 столбцов, но еще и отгребете проблему построения индексов. в вашем примере на товары, забавно будет посмотреть на то как вы будите по 1500 или 5к (это количество разных видов товаров) делать поиск по ограничивающему параметру. Вот у меня например автомобили, так там в комплектации постоянно что-то дабаляется, а что-то из списков выбора становится текстовым значением, что-то просто есть/нет (кондицианер, люк и пр.) Второй момент такой, что по скорости вы резко получаете выйгрыш после того как набрав статистику вы перенесете часть параметров в первычные. В конце концов убеждать я вас не собираюсь, я ж делюсь решением, а не навязываю его.
если же у вас ограничения по поиску выделяют всего 1/100 или даже 1/20 таблицы, то все летает ибо используется праймари индекс
вот видно — не внимательно читал:
>а практике, при решении подобных задач всегда находится набор свойств…
они попадают/качуют в первичные, написано же:
«выделить первичные (наиболее используемые в поиске) и вторичные свойства сущности, по первичным свойствам создаем таблицу»
еще раз повторюсь: если ты например осваиваешь новый рынок, то не знаешь какое поле будет наиболее употребительно для поиска.
второе: уневивирсальное решение — хороший метод для анализа.
вот сделаешь ты мега читаемую таблицу на 40 столбцов, а окажется она заполена на 20%, будут ли у тебя индексы работать? нет.
а кстати у вас все ограничения в таблицу класть. id нименования, поле, возможные переходы.
ваш SELECT * FROM oil будет использовать максимум один индекс, а значит если в базе 1024 товаров, из них половина в price < 30, и 1/4 в AND type in ('Castrol','Mobile'), то будет использован индекс на поле type (у вас ведь нет индекса на price+type) собственно выделив 1/4 вы дальше по базе результату пойдете простым перебором.
в случае полной нормализации ВСЕ ждойны происходят с оператором on, который задает связь по первичному ключу + если весит индекс на value то поиск по всем полям будет вестись по бинарному дереву ибо на все эти джойны будут наложен один индекс а не несколько.
а ведь есть и поля которые чисто технические (кол-во на складе) и тогда запрос: все товары, которых менее 100 на складе и размером не более 100см будут у вас бегать по разным таблицам и гемору вы отгребете не менее чем на написание конструктора SQL запроса (что я сделал за вас)