|
Задавайте вопросы, мы ответим
Вы не зашли.
Суть проблемы такова. Скажем, есть сайт по продаже спецтехники. У каждой спецтехники есть свои общие поля. Такие как: тип спецтехники, цена спецтехники, цвет и тд. И есть свои уникальные характеристики. Например: у автокрана: длина стрелы и длина лебедки, а у экскаватора: глубина копания и объем ковша, высота выгрузки и тд.
Так вот как мне организовать архитектуру своих таблиц, что бы можно было искать по уникальным характеристикам. Пример вывода фильтров можно посмотреть на alibaba . com и www. ebay . com
Если можно то примерную архитектуру и MySQL запрос. Буду очень благодарен.
Неактивен
Здесь быть не может одного единственного универсального запроса, равно как и универсальной структуры.
Можно представить экскаватор и педобира - обобщённым классом объектов, составить для них таблицы общих для всех экземпляров класса - характеристик (таблица цветов та же самая).
Также вполне возможна ситуация, когда три экземпляра объектов имеют общие, но непересекающие характеристики. Например добавим к нашему мишке и экскаватору - ну скажем сферическую чууниевую трубу. Мы видим, что мишка и экскаватор - имеют общее свойство "цвет", а экскаватор и труба - имеют общее свойство "чугуниевые".
Надеюсь, уже стало ясно, что одним запросом тут не обойтись, равно как и некой одной суперуниверсальной таблицей. Также надеюсь - стало ясно, что за внешней простотой и функциональностью подобной реализации (на том же ебее к примеру) - скрывается весьма сложная серверная логика, и структура базы данных. (Или вы думаете, ебей индусы кодили, за еду?).
И не у всех хорошо и правильно получается реализовать подобную систему. За печальными примерами - далеко ходить не надо - 1С...
Неактивен
Ну, перефразируя немного другими словами — действительно имеет смысл сделать
несколько независимых табличек для разных видов техники.
Неактивен
Конечно, для создания интернет магазина только под тематику продажа спецтехники, лучше разделить по таблицам. Тем боле не так много разделов. Но когда хочется написать что то оптимальное . что бы можно было без всякого труда перепрыгнуть с одной тематики на другу. То, рыская вчера по интернету, наткнулся на очень интересную архитектуру. И называется она Entity Attribute Value.
http://en.wikipedia.org/wiki/Entity%E2% … alue_model
Всем спасибо!
Неактивен
Дада, так начинают делать все, а потом начинают спрашивать: «а почему оно
у меня работает так медленноооооо?». А ответ простой. Если в нормальных условиях
у Вас табличка на 10 000 строк с 10 полями, то в этом случае у Вас табличка на
100 000 строк с тремя полями, т.е Вам нужно делать в 10 раз больше перемещений
головки по диску (не считая того, что нужно прочитать в 30 раз больше одинаковой
информации).
Неактивен
