Форум MySQL

Вот такой вопрос: в базу инет магазина заносится товар. У товара есть некие параметры (производитель, модель, размер, цвет).
Имеет ли смысл составлять нормализованную базу из отдельных таблиц (таблицы производителей, моделей, цветов, размеров и тд) или забить все в одну таблицу? Во втором случае упрощается поисковый запрос (и по времени выигрыш - запрос к одной таблице, а не к пяти), но база становится больше. А в первом варианте -цветов - не более 12, стоит ли под 12 цветов таблицу создавать? Насколько критичен размер, если записей будет не более 2-3 тысяч?

Какие есть еще плюсы и минусы у этих вариантов и чем руковадстваться при проектировании базы?

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

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

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

мне кажется, удобнее все в одной таблице держать (для магазина). при этом вспомогательные поля (производитель, цвет, размер, марка) можно заполнить только, введя новый товар (или отредактировав старый). ну и правильно, а зачем нам хранить производителей, если товара такого нет в данный момент в таблице? у меня были прайсы в 1,5-3 тысячи строк. при этом они менялись почти каждый день. в отдельной таблице я хранила только наценки, их админ может установить на категорию целиком или на отдельный товар. тогда при загрузке нового товара, ему сразу ставились в соответствие наценки, которые сохранились с прошлого редактирования прайса в другой таблице.

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

Нет, реляционная база это ИМХО лучшее на сегодняшний момент решение... Пока XML до конца не доделают...

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

Откровенно говоря, не понял организации таблицы. Не поясните?

CREATE TABLE price (   id varchar(10) default '0',   price decimal(6,2) default '0.00',  /////////цена оптовая   offer varchar(30) default NULL, ///////////линк на фотку, в другом магазине - пустое поле, у них фотки по id вызываются   availab varchar(20) default NULL,  ////////////есть ли товар на складе. наверно, тут хватило бы и одного символа   famcat varchar(50) default NULL, /////////// family category   subcat varchar(50) default NULL, /////////// subcategory   manuf varchar(100) default NULL, ////////// manufacturer   marka varchar(50) default NULL, /////////// marka   descr longtext,  //////////// описание товара   retprice decimal(6,2) default '0.00',  ///////////// розничная цена   kerdos decimal(4,2) default '0.00', ///////////// наценка (%)   eshop char(1) default 'N',  ////////// виден ли товар на сайте (тоже только в одном магазине заполняется, в другом видны все товара, у которых установлена наценка)   apopou varchar(50) default NULL ///////////// поставщик (для организации загрузки прайсов от разных поставщиков) ) ENGINE=MyISAM;

товар можно добавлять и по одному. есть специальная форма. в ней DISTINCT'ом выбираются определенные поля
и строится выпадающий список из них. если в списке нет нужного производителя или марки или еще чего-то,
заполняется текстовое поле с нужным значением. товар заносится, вместе с ним заносится и новый (новые)
производитель(марка и т.д.) и, если нужно занести еще один товар, то в выпадающих списках уже есть все эти
значения.
допустим, админ пошел заносить товар. вдруг видит, что нет нужной фирмы. ему надо оставить форму ввода
товара и идти заносить фирму, потом выбирать ее из списка, вернувшись в форму ввода товара. а если
таких действий много требуется? тут же озвереешь...
а если кто-то умный возьмет и удалит из таблицы производителей строку? а его товар в другой таблице при
этом останется...
или, допустим, в таблице фирм будет забито 100 (200,300) строк. а прайс на след. день придет только на одну? это
не распухание базы?

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

Нет, тут всё ясно...
Эта таблица сродни классической таблице users. Там же мы тоже редко пишем справочную таблицу куда заносим все названия городов или улиц (хотя по идее надо бы :)).
Но у вас наверное задача просто отображать на сайте товары.
А представьте теперь что вам надо работать с производителями. Т.е. например вести учёт поставок, взаимозачётов и т.д. Тгда вы в каждой таблице будете писать название производителя?
>или, допустим, в таблице фирм будет забито 100 (200,300) строк. а прайс на след. день >придет только на одну?
Ну надо бы определится. Если база хранит только мгновенное состояние склада тогда да реляционная база не целесообразна. Аесли нужна история тогда таблица из этих 100,200,300 фирм очень даже пригодится.

задача была - ежедневное, быстрое и максимально упрощенное выкладывание на сайт прайсов сторонних
организаций. при этом содержание прайсов становилось содержимым e-shop'a (или автоматически после
добавления наценки или после отметки админа). никакой статистики, никакого анализа, никакого хранения.
старые прайсы затираются новыми (вообще-то есть выбор - добавлять или заменять прайс).

Тогда естественно не нужна никакя реаляционная БД.
Идеологически (не учитываем скорость) можно было бы текстовым файлом обойтись

- Так посмотрим таблицу :)

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

Так вот я к тому, что на распухание при 2-3 тыс. записей, наверное можно не обращать внимание? А изменение всех на званий тоже просто делается - выберем уникальные значения, выведем их списке формы SELECT и скриптом все поменяем... Я почему иначал эту тему - я пока не вижу серъезных преимуществ нормализованной базы для малых таблиц (неск. тысяч строк). Вот и хочу понять, есть ли они. (Это все, конечно, от двигателя прогресса (лени) - не хочется усложнять скрипты и запросы.)
Для больших - согласен, есть серьезные доводы (размер). А вот для малых? Вот , скажем, 10 производителей, 100 моделей, 10 размеров, 10 цветов