Вопрос - оптимальная структура БД для каталога автопродаж

[Zenich]

Вопрос - оптимальная структура БД для каталога автопродаж

Добрый день, уважаемые форумчане.
Сел вот за разработку каталога автопродаж и ормаю голову над реализацией БД.
Условия таковы, что параметры описания каждого конкретного автомобиля будут неизменны (т.е. поля опций как то: цвет, наличие кондиционера и т.д будут фиксированными, заказчик дал пример сайта, попросил такие же поля и сказал что ничего меняться либо добавляться не будет).
И я вот думаю, корректно ли будет сделать такие таблицы:

1. Непосредственно таблица с автомобилями, содержащая ВСЮ информацию о машине ...
2. Таблица бренды/модели - древовидная (id, parent_id, name)
3. Таблица с перечнем основных характеристик: тип двигателя, объем, тип трансмиссии (id, codename, name) - codename (benzin, diesel) будет вставляться в соответствующее поле таблицы 1
4. Таблица с перечнем опций: парктроник, ксенон и т.д. построенная по принципу таблицы 3

Т.о. поиск будет проводиться только по одной таблице, все остальные выполняют "обслуживающую" роль для внесения данных (построения выпадающих менюшек выбора) и дают возможность управлять второстепенными параметрами (по каждому параметру добавлять/удалять допустимые для него значения).

Собственно прошу более опытных коллег покритиковать, указать на слабые места такой структуры, возможно предложить что либо более оптимальное.

По форуму искал, нашел только одну ветку с похожим вопросом, но там обсуждение свелось куда то совсем не по теме и затихло.

Заранее благодарен за ответы/советы.

-~{}~ 06.10.09 14:40:

Так-с, ответов нету Ну неужели никто не сталкивался с подобной задачей ?

Ладно, тут поступили новы вводные, задачу усложняю

1. Мультиязычность.
2. Возможность добавлять/удалять опции и параметры описания для каждого автомобиля.


Хочу попробовать вот такой вариант:

1. База будет денормализованная, все описание машины будет в одну строку в таблице, имена сотлбцов - соответствую существующим опциям и параметрам

2. Создаю 2 таблицы с названиями опций и параметров *при изменении, соответствующи столбцы будут убираться/добавляться в основную таблицу со ссписком машин).

3. Создаю таблицу языков, при добавлении языка - добавляем соответствующие сотлбцы в предыдущие 2 таблицы описаний параметров.

По моему мнению:
Плюс - проще организовать поиск
Минус - понятия не имею как все эти добавления/удаления столбцов отразятся на производительности ...


Люююдииии, ну хоть кто то откликнитесь, пожалуйста ......

 

[findnext]

База будет денормализованная,

ай ай ай... сначала сделай нормализованную структуру. Оптимизировать будешь потом

-~{}~ 06.10.09 14:46:

нарисуй в UML для начала и тогда покажи

 

[nirex]

3. Создаю таблицу языков, при добавлении языка - добавляем соответствующие сотлбцы в предыдущие 2 таблицы описаний параметров.

Шаткая структура, все надо глазками и ручками проверять. Делай обычно, сможешь внешние ключи навесить, очень необходимая вещь.

2. Таблица бренды/модели - древовидная (id, parent_id, name)

Поменяй на nested sets, упростишь себе логику получения данных

 

[Beavis]

но усложнишь изменение

 

[findnext]

gentable
id name item1id item2id item3id item4id

item1
id
name

item2
id name

item3
id name

в результате для поиска главной таблице придётся во where только разные ид подставлять. После того как найдутся данные можно будет выбрать названия items по id

-~{}~ 06.10.09 17:31:

Создаю таблицу языков, при добавлении языка - добавляем соответствующие сотлбцы в предыдущие 2 таблицы описаний параметров.

тогда items будут выглядет так

item1
id
name_rus
name_eng

-~{}~ 06.10.09 17:32:

+ индексы на каждое поле в ген таблице. Не думаю что их будет много, максимум 15

 

[Zenich]

Автор оригинала: nirex
<skiped> Делай обычно, сможешь внешние ключи навесить, очень необходимая вещь.

Поменяй на nested sets, упростишь себе логику получения данных

Да дело в том если бы я знал как это "обычно"
Я мультиязычных только два сайта делал, но они простенькие были, в первом просто набор переменных фраз из соответствующего текстовика языкового тянул, а во втором там вообще мало было переменных зависящих от языка, и я все отдал на откуп SMARTY, он у меня сам разруливал, единственное только что в базе все тексты были в двух языках и я выбирал необходимый вариант порсто подстановкой окончания колонки в зависимости от рельтата, примерно так: index.php?lang=ru и выбиралась колонка типа description_ru по принципу SELECT discription_$lang .... ну и т.д.

А про nested sets я сейчас почитаю, спасибо за подсказку !!!!

-~{}~ 06.10.09 18:39:

Автор оригинала: findnext
gentable
id name item1id item2id item3id item4id

item1
id
name

<skiped>

+ индексы на каждое поле в ген таблице. Не думаю что их будет много, максимум 15

Ок, огромное спасибо !
Ща по первому варианту почитаю умных книг, и этот тоже попробую !!!!
Еще раз спасибо за подсказки !

 

[nirex]

сделай сначала без мультиязычности, обкатай общую схему, а потом приделаешь еще языковую структуру, конечно алгоритм усложнится и придется немного по переносить данные, а где-то всего лишь поле добавить и из простого уникального индекса сделать составной.
На счет обычной структуры, поищи на форуме, тут точно это обсуждалось и называется вроде "универсальный каталог"
Вот только вся универсальность плоха тем, что она необычайно тормознутая, но гибкая. А в твою будет сложно добавить еще что-то кроме машин, к примеру мото.

индексы на каждое поле в ген таблице. Не думаю что их будет много, максимум 15

не советую так делать, над тобой жестко пошутили )))))))

делай как положено, не в столбец, а в строку. инфы по этому поводу море.

есть еще одна проблема юного разработчика, многие пытаются сразу внедрить кучу фич,которые в результате могут не понадобится, в итоге сайт остается либо сильно сырой , либо совсем неокончен.

 

[Zenich]

Автор оригинала: nirex
<skip>
На счет обычной структуры, поищи на форуме, тут точно это обсуждалось и называется вроде "универсальный каталог"
Вот только вся универсальность плоха тем, что она необычайно тормознутая, но гибкая. А в твою будет сложно добавить еще что-то кроме машин, к примеру мото.

Да дело в том что сначала не сказали что нужно будет управлять полями, просили фиксированные. Но мне честно говоря и самому хотелось сделать гибкую систему, так как на этой основе потом еще несколько аналогичных сайтов планируется.

Автор оригинала: nirex
не советую так делать, над тобой жестко пошутили )))))))

Спасибо за предупреждение

Автор оригинала: nirex
делай как положено, не в столбец, а в строку. инфы по этому поводу море.
есть еще одна проблема юного разработчика, многие пытаются сразу внедрить кучу фич,которые в результате могут не понадобится, в итоге сайт остается либо сильно сырой , либо совсем неокончен.

я как раз за фичами и не гонюсь, сам не люблю когда много лишних прибамбасов, которыми не пользуется никто. Просто хочется сделать так чтобы дать заказчику максимум возможностей по управлению сайтом, чтобы потом не дергал по поводу доработок.

Еще раз спасибо за информацию и подсказки !

 

[nirex]

Просто хочется сделать так чтобы дать заказчику максимум возможностей по управлению сайтом, чтобы потом не дергал по поводу доработок.

Заказчику надо дать,то чего он хочет, возможно где-то поправить, но не давать больше. Если тебе хочется вложить сил в этот проект делай грамотнее, дай ему что он попросил вместе с твоими коррективами. А после успешности и его одобрения, что проект ты выполнил качественно. Скажи, что тебе приходят гениальные идеи как улучшить его бизнес вот с этими максимальными возможностями. И желательно чтобы у тебя была уже готова цена на каждую такую возможность.
Скорее всего он не сразу примет решение доделывать сайт, но будет знать и прикидывать как ему это действительно поможет.
А у тебя будет время на изучение материала без особой гонки, к примеру новой политики вывода данных используя новшества маркетингового хода идущий как модуль к твоему проекту.

 

[findnext]

делай как положено, не в столбец, а в строку. инфы по этому поводу море.

не мог бы ты пожалуйста пояснить, что значит эта фраза?

-~{}~ 07.10.09 11:19:

я просто привел самый простой пример нормализации данных, считаю что это необходимо на первом этапе при любом проектировании бд.

 

[nirex]

findnext
http://ru.wikipedia.org/wiki/Нормальные_формы

я просто привел самый простой пример нормализации данных

Что же это за нормализация, если необходимо использовать для каждого языка свой индекс

Должна быть такая структура:

CREATE TABLE `items` (   
`id` INTEGER(11) NOT NULL AUTO_INCREMENT,  
`lid` INTEGER(11) NOT NULL,   
`name` VARCHAR(20) COLLATE utf8_general_ci NOT NULL DEFAULT '',  
 PRIMARY KEY (`id`),  
 UNIQUE KEY `id` (`id`, `lid`),  
 KEY `lid` (`lid`),   
CONSTRAINT `items_fk` FOREIGN KEY (`lid`) REFERENCES `languages` (`id`) ON UPDATE CASCADE )
ENGINE=InnoDB AUTO_INCREMENT=1 CHARACTER SET 'utf8' COLLATE 'utf8_general_ci';

CREATE TABLE `languages` (
  `id` INTEGER(11) NOT NULL AUTO_INCREMENT,
  `code` VARCHAR(3) COLLATE utf8_general_ci DEFAULT NULL,
  PRIMARY KEY (`id`)
)ENGINE=InnoDB
AUTO_INCREMENT=1 CHARACTER SET 'utf8' COLLATE 'utf8_general_ci';

 

[findnext]

для каждого языка не нужно использовать свой индекс, где я об этом писал?

-~{}~ 07.10.09 12:27:

не вижу смысла в таблице languages

-~{}~ 07.10.09 12:29:

Models
id
name_rus - Мазда
name_eng - Mazda

индексами будут служит первичные ключи

и так для каждой таблицы. Выборка то всё равно всегда будет происходить по ИД. А выбрать соответственное название можно подставив код языка.

SELECT name_'.$lang.' FROM blabla WHERE id = 1

-~{}~ 07.10.09 12:34:

зачем использовать дополнительные таблицы когда можно обойтись одной

 

[nirex]

findnext
подумай
Даю подсказку, кроме имени появляется еще поле описание, тоже сделаешь таким же способом как с именем ?

 

[findnext]

nirex
не вижу ничего плохого в том чтобы так делать. Конечно мой вариант потребует создания 3 полей вместо твоего одного + таблица языков.

у тебя стоит UNIQUE KEY `id` (`id`, `lid`) - полностью одобряю.

Это уж как ТС решит как ему лучше сделать.

-~{}~ 07.10.09 12:44:

Хочу заметить что в обоих случаях имеются свои преимущества и недостатки по сравнению с дугим способом.
Мне твой способ нравиться но это не означает что и мой способ не имеет права на существовние

 

[nirex]

findnext
конечно имеет, палкой копалкой и в наше время можно пользоваться, только не очень она используема в средних и крупных масштабах

 

[findnext]

nirex
приведи аргументы

 

[nirex]

))))))))))))))))))))))))))))))))))))))
Ладно сделаем как в дет садах, для обоих вариантов нареж полоски из бумаги подели их на колонки и поиграйся, если разницу не чувствуешь сделай больше таких нарезанных строк. Представь, что ты не один разработчик а вас несколько, кому необходимо работать с такой структурой, и вы связаны корпоративными правилами, чаще всего структуру таблиц менять вообще нельзя.
В общем я заканчиваю сюда писать.

 

[findnext]

nirex
твой способ 100% правильный и с этим не спорю. Раньше я всегда так делал. Свой способ я предложил как вариант и всё.

 

[Zenich]

Автор оригинала: findnext

не вижу смысла в таблице languages

-~{}~ 07.10.09 12:29:

Models
id
name_rus - Мазда
name_eng - Mazda

индексами будут служит первичные ключи

и так для каждой таблицы. Выборка то всё равно всегда будет происходить по ИД. А выбрать соответственное название можно подставив код языка.

SELECT name_'.$lang.' FROM blabla WHERE id = 1

-~{}~ 07.10.09 12:34:

зачем использовать дополнительные таблицы когда можно обойтись одной

А вот позвольте не согласиться батенька ....
Смотри, у меня есть таблица languages:

id - integer
lang - varchar
name - varchar

к примеру так, заполненая строка выглядит так:

id: 1
lang: ru
name: Русский

И хозяин сайта может в админке добавлять/удалять языки, и по этойже таблице по параметру lang мои скрипты определяют какое окончание подставлять при запросе к другим таблицам, как ты и написал выше: SELECT name_'.$lang.' FROM blabla WHERE id = 1


а если бы ее не было - то получается, что языки забты жестко, и рулить ими уже никак