Проектирование базы данных

Есть вот такая задача.
Хочу написать движок для доски объявлений. Там будут разделы. В каждом разделе свой шаблон объявления, то есть у объектов из разных разделов разные свойства. Например автомобили и фотоапараты. У фотоапаратов нет объем двигателя, а у авто нет количество мегапикселей итд.

Так вот в чем вопрос. Как лучше всего хранить эти свойства? Нужны отдельные поля, так как будет поиск по большинству из них, и хранение в одном текстовом поле вряд ли подойдет тут.

Таблица с полями id поля id товара значение. здоровая она только будет.
Ну и соответственно у самого товара сделать поле куда сложить сериализованный набор характеристик. Такой себе кэш.

Цитата ("frig"):

Таблица с полями id поля id товара значение. здоровая она только будет.

то есть хранить свойства в отдельной таблице и связать по ID объекта? Подумал об этом. И даже подумал о том что бы создать несколько таблиц:
props_float, props_text, props_int итд.
Вопрос в том как все это работать будет. Не пострадает ли скорость?

WebDesignStudio, можно и в одной таблице. Иначе придется делать 3 запроса. Мы то не знаем какие поля у товара до выборки? Можно дробить по другим критериям, по категориям, например. Но это уже не красиво совсем.
Скорость при выборе по полям может быть и не космическая будет, но работать будет. У меня есть пример работающего на такой базе кода. Выборка непосредственно товара не пострадает - там кеширование.
Тут главное не пытаться вырулить все одним супермега sql запросом
У меня получалось один запрос на каждый заданный параметр. Редко кто будет больше 3-х указывать, я думаю.

Цитата ("frig"):

WebDesignStudio, можно и в одной таблице.

ну это да. но зато числовые и булевские значения не будем хранить в полях varchar.

WebDesignStudio, вообще то я пришел к тому, что там в поле должны быть только числа. Никаких строк.

Хм. Как это?

Как без строк в смысле? Строка очень не удобна для хранения такой информации. Там получается 3 основных типа - булев (есть/нету), просто значение (напряжение, длина, вес) и перечислимый - всякая иная муть. Если допустить строки, то по ним будет очень сложно точно искать, по ним толком ничего не сгруппировать - народ понапишет туда такого, что мало не покажется. Ну и для меня тогда еще был важен перевод. Цифры переводить проще всего

А если например цвет, адрес итд?

Цвета есть основные, по которым разумно искать и есть серобуромалиновый, который в поле поместить можно, а вот искать по нему врядли кто-то будет. Так зачем он тогда нужен?
Поиск по адресу? Не приходилось. Страна, город - перечислимый. Остальное в комментарий по которому никто не ищет. Всякие телефоны и иже с ними.
Кстати тот же город. Одно дело каждый напишет отсебятину и поди потом найди среди днепр, днепропетровск, днепроперовск, дніпропетровск, дніпропетровськ и так далее что-то найди. А когда это город с вполне конкретным id, то проблем нет. Нормализация рулит

Еще есть момент с приведением значений к "общему знаменателю". Все знают, что 800 грамм и 0,8 кг равны (ну примерно ) а вот машина 0.8 и 800 будет сравнивать их вполне серьезно. Как и метры/миллиметры, миллиампер часы и ампер часы и так далее. Дай пользователю ввести в поле строку и потом поди угадай что это на самом деле.

Хм. Ну для поиска понятно. Но эти свойства(строковые) все таки нужно хранить как то? Можете показать структуру таблицы, а то я не очень понял?

Вид топлива, тип трансмиссии (для автомобилей)
ну это точно нужно строковым значением хранить.

Ваша идея не плохая, так как большинство свойств, действительно можно как число хранить. О. Еще есть марка авто, тоже строковое.
так что наверное лучше, сделать по таблицы на каждый тип данных. Да получится 3 запроса. Что будет лучше тут, 3 запроса, или хранить числа в varchar?

Цитата ("WebDesignStudio"):

Вид топлива, тип трансмиссии (для автомобилей)

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

Цитата ("WebDesignStudio"):

Но эти свойства(строковые) все таки нужно хранить как то?

Только в виде перечислимых значений. Выпадающий список если угодно.

Цитата ("WebDesignStudio"):

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

Так а что не понятно то? в таблице храним в одном поле либо непосредственно значение (float), либо признак наличия/отсутствия (0,1), либо идентификатор значения перечислимого (1-бензин, 2-диз топливо, 3-газ). В отдельной таблице храним соответствие 1,2,3 для типов топлива, цветов, типов кузовов, размерностей шин и так далее.

Как найти машины на газу, если один пишет "газ", второй "пропан", третий "ГБО"?

Цитата ("WebDesignStudio"):

Ваша идея не плохая, так как большинство свойств, действительно можно как число хранить.

Их все можно хранить как числа.

Цитата ("WebDesignStudio"):

О. Еще есть марка авто, тоже строковое.

Тоже перечислимый. Их ограниченное количество. Как и производителей как и много другого.

Цитата:

Да получится 3 запроса.

Нет, получится количество полей в выборке * 3

Цитата ("frig"):

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

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

Цитата ("frig"):

Нет, получится количество полей в выборке * 3

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

Цитата ("WebDesignStudio"):

к сожалению не выход. Таких таблиц может быть бесконечное число.

зачем бесконечное-то? не пойму. Одни таблица с параметрами, одна с перечислимыми значениями.

Цитата ("WebDesignStudio"):

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

Тоже верно. Но смысла особого нет.

Я бы делал примерно так:

items
|id|name|propertiesgroup_name|
1 - фотопарат кенон - фототехника
2 - камера сони - фототехника
3 - нисан патрол - автомобили
4 - мерседес 450мл - автомобили

properties
|id|name|
1 - количество пикселев
2 - цифтовой зуум
3 - объем двигателя
4 - мощность киловат (л.с.)
5 - поддержка карт SD
6 - поддержка карт microSD
7 - кожаный салон

properties_groups
|id|name|properties_id|
1 - фототехника - 1
2 - фототехника - 2
3 - фототехника - 5
4 - фототехника - 6
5 - автомобили - 3
6 - автомобили - 4
7 - автомобили - 7

properties_values
|id|item_id|propertion_id|value|
1 - 1 - 1 - "10 mpx"
2 - 1 - 2 - "40 mm"
..
10 - 4 - 7 - "yes"

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