Как правильно расположить данные в базе данных mysql?

Question

[l2p]

Здравствуйте,

Есть некоторые данные - связка {id, price}. У каждого товара может быть десяток таких связок а может и не быть. На данный момент я создал 20 полей и большинство из них полупустые. Может есть смысл положить данные в одну ячейку. Читал про сериализацию, но выгодно ли ее использовать при добавлении в секунду более 200 записей?

Answer 1

[Dave]

Почитай про нормализацию данных. В текущей задаче - это One-to-Many Relationships
Сериализация в данном случае не верный подход, потому что:

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

А так в целом, если у одного товара может быть несколько цен (теоритически - да хоть тысяча цен - не важно), то всё это должно хранится в отдельной таблице. И выбиратся джоином как One-to-Many Relationship.

Answer 2

[Никита]

Необходимо привести БД к одной из нормальных форм:

Первая нормальная форма (1NF)
Вторая нормальная форма (2NF)
Третья нормальная форма (3NF)
Четвёртая нормальная форма (4NF)
Пятая нормальная форма (5NF)

Comments

[l2p]

Никита Спасибо за ответ. То есть Вы считаете, что более правильным решением будет разбить таблицу на части?
Мой вопрос также сводится к: >> Просто и так очень большое количество запросов в транзакции (как и говорил ~ 200 штук) и если добавить еще столько же инсертов и селектов для последующей выборки по id-шникам, то база будет просто не справляться.

[Сергей Протько]

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

[Никита]

l2p: Нормализация базы, как раз таки и придумана для оптимизации запросов. Дело не в количестве запросов, дело в том, по какому количеству данных будет вестись поиск и сколько лишнего придётся подтянуть из каждой таблицы.
Можно сделать одну огромную таблицу, в которой будут повторяться данные и в конечном итоге, она разрастётся до огромнейших размеров, и время затраченное на поиск по такой таблице, уже будет идти на минуты. А можно сделать несколько маленьких таблиц, приведённых к 3-ей нормальной форме, по которым поиск будет осуществляться гораздо быстрее, из-за их маленького размера и оптимизации.

Answer 3

[skvot]

Если я Вас правильно понял, то у вас обычная связь многие-ко-многим?

product
--------
id | name

price
------
id | value

product_to_price
-------------------------
product_id | price_id

Хотя я бы просто сделал таблицу цен

price
---------------
id | product_id | value

Comments

[l2p]

skvot Я посчитал, что нет смысла в дополнительной таблице, так как обработка идет практически налету и все данные лежат в одной таблице. Просто и так очень большое количество запросов в транзакции (как и говорил ~ 200 штук) и если добавить еще столько же инсертов и селектов для последующей выборки по id-шникам, то база будет просто не справляться. Или я не прав?

[Сергей Протько]

l2p: и? причем тут запросы с транзакциями? Используйте табицу и связь один ко многим, оно решает вашу проблему целиком и полностью. Хотите что-то круче - меняйте mysql на postgresql, там есть массивы.