про нормализацию

[zuxel]

про нормализацию

У меня в таблице хранятся товары интернет-магазина, каждый товар может иметь следующие характеристики: длина, диаметр, малый диаметр. Эти характеристки имеют не все продукты и получается, что есть делать одну большую таблицу:
id | title| category_id | descr | length | diameter | diameterm ...
то получается, что у многих строк значению будут заполнены нулями. Чтобы этого избежать можно завести три таблицы под диаметр, малый диаметр, длину.
Тогда каждый раз при работе с товарами придется обращаться не к одной таблице, а к четырем, что усложник процесс выборки, поиска и т.п, зато не будет лишних строк с нулевыми значениями, если у товара значение равно 0, то просто не записываем его номер в таблицу.
Как стоит поступить? Выбрать первый или второй вариант?

 

[akd]

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

 

[Alexandre]

вот я тебе отвечу второй вариант и рядом ответит хххх, что надо делать первый ... что тебе это даст?

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

ну а делать надо как-то так:

tab detal - таблица наименований деталей
id | title| category_id | descr |

tab parametr - таблица характеристик
id | name | value | unit | datal_id

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

 

[akd]

Alexandre,
угу, только чтобы это называлось нормализацией, то name & unit должны быть в третьей таблице ..

 

[MuXaJIbI41981]

делаем таблицу с товарами и таблицу со всеми возможными параметрами ...

а в третьей сохраняем связь тавара с параметром и его значние

 

[Alexandre]

угу, только чтобы это называлось нормализацией, то name & unit должны быть в третьей таблице ..

согл...
но если только мы имеем 4 параметра, то можно и 2 тбл

если параметров много, то нужно делать по вышепредложенным вариантам

 

[С.]

zuxel, оба варианта имеют право на существование. Что-то за что-то: либо более сложные вычисления, либо хранение излишних данных.

P.S. На данное время дисковое пространство стоит значительно дешевли вычислительного времени.

 

[zerkms]

Предлагаю альтернативный вариант:

Таблица с общими параметрами, которые есть у всех объектов: id, title, price, date_added, etc...
+ по 1 таблице на каждый из типов, в которой будут храниться уникальные характеристики

-~{}~ 22.01.10 12:39:

ну а делать надо как-то так:

не надо делать EAV, оно нежизнеспособно

 

[Splurov]

zerkms

+ по 1 таблице на каждый из типов, в которой будут храниться уникальные характеристики

Что под типами подразумевается? Типы значений?
Почему EAV нежизнеспособно?

 

[fixxxer]

Вопрос в том, что тебе нужно - красота архитектуры с точки зрения теории РСУБД или производительность.

Впрочем, если по всем этим полям нужен поиск в различных их комбинациях, то я бы для поиска прикрутил Sphinx (а если параметров очень много, и многие могут быть NULL (или defaults) - вообще хранил бы в сериализованном виде).

 

[zerkms]

Splurov

Почему EAV нежизнеспособно?

потому что жутко медленное и с тонной ограничений на выборки?

Что под типами подразумевается? Типы значений?

типы сущностей

fixxxer

(а если параметров очень много, и многие могут быть NULL (или defaults) - вообще хранил бы в сериализованном виде).

зачем тогда вообще база?

 

[fixxxer]

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

А так - бывает, что одновременно надо и обычные выборки по id, и вот такое, при том что РСУБД во многом удобна для остального. Не плодить же зоопарк из-за одного кейса.

-~{}~ 22.01.10 08:25:

Вот, кстати, недавно на тему пробегало: http://www.mysqlperformanceblog.com/2010/01/21/when-should-you-store-serialized-objects-in-the-database/