динамическая генерация таблиц в БД
Сталкнулся с такой задачей - нужна база товаров. Представляю себе это так:
есть дерево рубрик (недвижимость, автомобили, мобильные уст-ва и др.) и в каждой из этих рубрик будут товары со своими свойствами. Например для недвижимости - квартира может быть 1 комнатная, 2-х, 3-х, ..., первый этах, второй, ..., адрес, прощадь и др. Для автомобиля это цвет кузова, пробег, привод, производитель, топливо и др. Для мобильных устройств свои свойства.
Рубрики должны добавляться через админку, соответсвенно в БД должна генерироваться новая уникальная таблица под товары из этой рубрики, поля в которой должены быть заданы во время добавления рубрики.
Можно было-бы хранить все описание товаров в простом текстовом виде, но тогда пропадает возможность тонкого поиска. Например не получится найти все 1-комнатные кваритры или все переднеприводные автомобили. Даже если вынести такие товары в отдельную рубрику, все-равно появятся проблемы при поиске по нескольким параметрам (например производитель и привод).
В общем проблема в том, как сделать так, чтобы обычный Модератор мог сам добавлять новую рубрику, ведь ему нужно будет объяснять что такео БД, какие типы данных бывают. Про индексы я вообще молчу! И как это реализовать в виде html-формы - закрученная страница в которой есть кнопочка "Добавить поле" с выбором типа добавляемого поля?
Короче в голове бардак! Хочу выслушать ваш профессиональный подход к данной задаче. http://market.ngs.ru/ - проект, клон которого мне нужно написать. Там у каждого товара свои свойства. Как им это удалось? Как сделать, чтобы ребрики добавлялись обычным Модератором, а не программистом? Есть где глянуть примеры такой админки?
Очень медленный метод, огромные SQL запросы для выборки данных, но каждый товар может иметь уникальные свойства.
Вариант два: написание умной системы которая может сама создавать таблицы для новых типов товаров и уметь их изменять ALTER'ом при необходимости внесения или удаления свойств.
Очень быстрые выборки, но сложно написать. Каждый тип товаров может иметь уникальные свойства.
Возможны и другие варианты, гибридные.
на сайте bitrix есть возможность в демке полазить, там много всяких интерфейсов, может чего полезного найдешь
Можно поподробнее узнать про второй вариант
Можно поподробнее узнать про второй вариант
Конечно можно, никто не против.
Конкретнее вопросы. В общем я все описал уже.
CREATE TABLE `cat` (
`id` int(11) NOT NULL auto_increment,
`parent_id` int(11) NOT NULL default '0',
`title` varchar(255) NOT NULL,
`eng` varchar(255) NOT NULL,
PRIMARY KEY (`id`),
KEY `parent_id` (`parent_id`),
KEY `eng` (`eng`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
Для каждого раздела "умным" скриптом создаётся табличка, со всеми необходимыми свойствами по товару из этого раздела. Например для незвижимости это колличество комнат, тип планировки, этаж, этажность дома; соответственно для сотовых телефонов имеем: модель, размеры, смарт/не смарт и тд... Естественно где-то храним, для какой таблицы какие поля какие данные несут.
А вот теперь представим себе что в наш каталог попадает база тогоже НГСа, тоесть примерно 2 млн вариантов недвижимости, около 5 тыс телефонов и куча всего другого в свои таблицы. Всё пока хорошо, искать удобно (так как всё в пределах одной таблицы). Но! (форс-мажор) Нам надо срочно добавить новое свойство для группы товаров, например для недвижимости "форма собственности". Предвставь себе ALTER TABLE, который будес перестраивать индекс более чем у 2х млн строк, а если у нас таблица MyISAM (юзаем FULLTEXT) то таблица заблокируется и пользователи обломаются?
Если я неправильно понял что-то поправь. Просто я встречался с подобной системой, это такой гемор её поддерживать.
Да, чуть не забыл, колличество таблиц в базе данных ограничено, и бесконечно плодить уникальные таблицы для каждой группы товаров мы не сможем
не удержался... ну так не юзайте убожество в виде MyISAM. и вообще откажитесь от MySQL ;-)
А кто сказал что я его использую? Дамп таблицы видел?
Я говорю про общую идею.
Хорошо, вот вопрос: второй метод, про который ты говорил, это то что описал я?
Если да, то первый значительно удобней и нет там никаких страшных запросов, всё зависит от того как спроектируешь структуру таблиц под параметры.
Кто там в разделе БД грозился за такие сообщения штрафовать вплоть до бана? :)
Первый вариант будет работать медленно. Медленно, хотя и достаточно гибко. Я когда-то что-то подобное делал.
Пока не замечал что это медленно работает. Единственная проблема - это поиск по этим параметрам. Сфинкс тут не прикрутишь, так как он пока не умеет искать по таким таблицам, хотя можно сэмитировать через MVA, а простой поиск требует либо несколько джоинов (по скольким параметрам ищем, столько раз и таблицу джойним), но тут ограничение в 32, либо OR и HAVING, что тормозит, так как индексы не юзает.
Я пока одно решение нашёл. Разбросал данные по полям, типа целые хранятся в одном поле, дроби в другом, словарные тексты в третьем (по этим полям строим составные индексы), а по чему не ищем храним в поле типа TEXT. По скольки параметрам ищем столько запросов и делаем, а потом ищем пересечение.
Если есть ещё какие варианты - просветите.
Да, он самый. И это весь вопрос?
Ты меня поравить в чем-то хочешь? Не понимаю смысл твоих сообщений в мой адрес.