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

frig, Как вариант. Но, если заранее известно каких типов будут товары - можно и сразу. Или неизвестно?

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

Я бы сделал:

Одна таблица для хранения информации о товаре. Типа
id | catId | titile | type

А дальше для каждого type отдельная таблица со специализированными полями.

Таких таблиц получится очень много. десятки или сотни. Не выход.

Вот как я поступил:

Небольшой вступ:
Для чего нам характеристики ?
- они нам нужны для отображения и для поиска

Как лучше отображать?
- отображения - это только то что видим, значит характеристики можем откудато там себе получить и держать в 1 поле, как многострочный текст (всеголиш 1 запрос!), а нафик нам больше! Тоесть чтобы в 1 записи хранилась вся информация о сущности, это крайне важно! Плодить и дергать каждый раз кучу таблиц, чтото там анализировать и т.д. совершенно глупо в висконагруженных системах, так не делается. Если надо быстро - то плевать на небольшой мусор в БД, главное скорость выборки!

Откуда собирать характеритстики в 1 поле?
- это уже не столь важно откуда, можно с отдельных таблиц или как вообще лучше придумаете для поиска, здесь уже смотрим на опять таки - быстрый поиск, вот наш критерий, поэтому лучше хранить такие вещи в отдельных таблицах. Ну и что что напр. у нас будет 100 разных характеристик? Это комуто интересно? Влом руки марать? Каждый день добавляете/удаляете категории или характеристики? Нет! Важен быстрый поиск! Более того план выполнения в таких таблицах будет меньше чем для модели "все в 1 куче".

Рассмотрим небольшой пример:
я ище телефон Nokia, с камерой > 3 мп

как задать юзер часть?
выбрал категорию - подгрузился фрейм с характеристика и выбрал характеристики

сколько запросов к БД будет для поиска?
1 !!!

Данный метод удачно цветёт и пахнет на одной БД (порядка 40 Гб, MSSQL 2005) уже несколько лет, пашет зверки быстро

Важно здесь понять, вы для себя времья экономите или хотите мегабыстрий магазин? Спросите заказчика, скоректируйте цену относительно его желания, если хочет подешевле - то фиг с ним, смотрите на VirtuaMart, как там всьо житвет это дело и лепите скрипт, который будет долго думать и делать кучу выборок.

MMM_Corp, не совсем понял как работает ваш метод. можете примерчик показать?

Что именно вам непонятно?

в кратце еще раз:
для каждой группы товаров - своя таблица характеристик

напр.

мобильные телефоны - все характеристики мобил - в 1 таблице, тоесть для каждой отдельно

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

чтобы искать - нужно указать где ми ищем, напр. в статьях, мобильные телефони, трусы и т.д.
указали,
подгружаю готовую форму для указания характеристик, напр. цвет, или наличие AGPS напр.,
указал, жму поиск - поиск будет производится только в таблице характеристик, - тоесмть опять таки 1 табл., 1 запрос

при том что поиск от представления вообще можно гибко разнести на отедбные сервера даже без всяких проблем
тоесть тяжёлые операции поиска можно будет вынести вообще отдельно от полустатики

вот в чом плюс моего метода

если хотите быстро - то просто запомните: минимум запросов, минимальный план выполнения, минимум кода, плевать на расходы места на винте!

Наверное вам интересно как подгружать фрейм с выбором характеристик?

да тут всьо просто, суть:

после добавления/удаления товаров/характеристик запускаю процедури:
1. очищения кэша
2. складирование характеристик с подчиненных таблиц в таблицу товаров
3. составление форм для поиска по характеристикам (здесь всьо просто, ряд запросов вида: select distinct(haracteristika) from haracteristika_tovara), и составление простого выбора для поиска чек-боксами (напр. выбрал Нокия, Самсунг (это в производителях), камера 3 Мп, 8 Мп, 5Мп (это веб-камера), слайдер, жаба (тип)) и нажал поиск
4. здесь опять таки сразу можно кэшыровать такие поиски, в простой форме: запрос - результат (БД будет вам благодарна)
5. морда была в виде десктопного приложения, никакого веба, поэтому кодом помочь не могу, как оно там вьо должно получится
примерно так это у меня сделано: ссылка, справа фильтра...

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

Ну и что тут такого?
ну ладно, поделюсь еще опытом:

можно все характеристики держать в 1 таблице!

таблица товаров
id,
id-товара

таблица характеристик
id,
id - значения

таблица значений
id,
s_name - значение характеристики

Тогда все характеристики можно индексировать (что это даст думаю знаете), и избавить от необходимости плодить таблицы, но скорость поиска конечно упадёт

с вас пиво!)

Я кстати оба способа сам знаю. Даже в практике использовал, но не в таких масштабах как хочу сейчас.

Ну если масштабы колосальные - то забудьте про MySQL, здесь уже: кластера, отдельные серваки, и чтото помощнее, PostgreSQL, Oracle, MSSQL, и всьо разделять, всьо кэшыть

а что за масштабы у вас такие предвидятся если не секрет?

MMM_Corp, все предложенное вами в топике уже предложено и вроде как даже более чем по одному разу.

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

frig, всей темы не перечитывал, вполне возможно что повторился, просто поделился своим опытом что уже делал и что отлично работает

Будет большое посещение, и много объявлений. Конкрентные цифры не могу назвать. Уже уговорил заказчика делать вот как:
Делать одну таблицу, в которой хранить общие свойства всех объявлений. А остальные свойства хранить в одно текстовое поле, с разделителями. Поиск так же делать только по общим параметрам+поиск по ключевым словам. Так получится один запрос. Отказываемся от дополнительных возможностей поиска и гибкости, но зато скорость будет намного выше.
Стоит ли этого делать? На сколько примерно будут потери производительности если нормальзовать?

WebDesignStudio, нормализация это в основном приведение системы к состоянию без избыточности, без лишнего хлама. В этом случае может страдать производительность, да. Но после того как все нормализовано и требуется повысить производительность - ставят кэши делают денормализацию. При этом происходит самое главное - остается явная четкая и правильная иерархия где собственно данные, а где копия. Это становится однозначно и понятно, остальная мишура только для повышения производительности.

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

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

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

Думаю в данном случае это лучший способ.

Это всегда лучший способ
Цитата ("WebDesignStudio"):

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

innoDB надо использовать и думаю будет нормально.

А как насчет mongoDB? Там записи в бд хранятся не в табличном виде, а что то типа ассоциативного массива с произвольным набором ключей(названий характеристик). Следовательно отпадает надобность в огромных таблицах харектеристик.

Вот как я спроектировал базу:

cats - таблица категории
`id` -
`root` - родительская категория
`title` - название
`alias` - алиас для использования в УРЛ
`order_list` - порядковый номер
`level` - уровень вложенности
`obj_count` - количество объектов
objects - таблица для хранения объявлений
`id` - уникальный идентификатор
`cat` - категория объекта
`city` - город
`user_id` - автор
`price` - цена
`p_date` - дата добавления
`photo` - фотография
`text` - текст объявления
`props!!!!!` - денормализованные свойства объекта(все в одно текстовое

поле для увеличения скорости при выводе информации)
`status` объявления '0-новое, 1-опубликовано, 2-блок,3-vip',
`ip` - ип адрес автора

obj_galery - фотографии объектов
`id` - уникальный идентификатор
`obj_id` - связь с объектом
`path` - путь к файлу
props_obj- дополнительные свойства объекта
`id` - уникальный идентификатор
`obj_id` - связь с объектом
`pname` - название свойства
`pvalue` - значение
`punits` - единица измерения
props_name - сппавочник названий свойств
`id` -
`title` - название
`cat_id` - связь с каткгорией
props_unit - справочник единиц измерения
`id` -
`value` - название
`cat_id` - связь с категорией
_________________________________________________________________________________________
Еще не успел делать описание всех таблиц.