Добрый день. Где-то видел подобную тему, но сейчас не нашел. Задача такая. Надо в MySQL  хранить заказы покупателей в интернет-магазине. Рассматриваю два варианта. Записывать в БД каждую позицию купленного товара (естественно с отметкой принадлежности к какому либо заказу.) Или для каждого заказа вставлять одну запись где и будет храниться массив со всеми купленными товарами. Хранить массив мне показалось лучше. В связи с этим нашел статейку как это сделать - http://ruseller.com/lessons.php?rub=37&id=699
 
Вопрос 1 как лучше хранить?
Вопрос 2 верить ли указанной статье?

серилизовать и хранить Еще в json можно

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

smv, это не лучший вариант. Причины:
1. Если тебе понадобится некая статистика аль ещё чего-нить подобное, то ты хрен её получишь нормальными методами.
2. Если удаляешь из базы некий товар, то в твоем случае в старом заказе будет "дырка". А в случае первого твоего варианта ты можешь при удалении товара из базы просто сделать некую отметку или прочее со всеми заказами, которые были на этот товар.
Нужно это для случая, если, к примеру, один товар просто удален из базы, так как ты передумал им торговать, другой удален так как больше не выпускается. А третий товар удален, так как менеджер дятел.
В общем, в любом случае если будет стоять некая отметка о причине удаления товара, то вполне возможно в заказе это отметить, или же даже банально сохранить только наименование удаленного товара в заказах.
 
Хотя, если магазин мелкий, то делай как тебе удобней. А хранить массив в БД удобно в помощью функции serialized().

Troy

серилизовать и хранить

Спасибо

master

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

По каждому заказу выбираю массив с id товаров. Выбираю товары в соответствии с id  их цену и отправляю по почте.

Givi

smv, это не лучший вариант. Причины:
1. Если тебе понадобится некая статистика аль ещё чего-нить подобное, то ты хрен её получишь нормальными методами.
2. Если удаляешь из базы некий товар, то в твоем случае в старом заказе будет "дырка". А в случае первого твоего варианта ты можешь при удалении товара из базы просто сделать некую отметку или прочее со всеми заказами, которые были на этот товар.
Нужно это для случая, если, к примеру, один товар просто удален из базы, так как ты передумал им торговать, другой удален так как больше не выпускается. А третий товар удален, так как менеджер дятел.
В общем, в любом случае если будет стоять некая отметка о причине удаления товара, то вполне возможно в заказе это отметить, или же даже банально сохранить только наименование удаленного товара в заказах.
 
Хотя, если магазин мелкий, то делай как тебе удобней. А хранить массив в БД удобно в помощью функции serialized().

О спасибо... будет над чем подумать.

smv

В связи с этим нашел статейку как это сделать - http://ruseller.com/lessons.php?rub=37&id=699

Частная коллекция качественных материалов для тех, кто делает сайты

ложь, пиздешь и провокация

Классический вариант в виде таблицы id заказа - id товара лучше. Подумайте, например, над простой задачей - "вывести все заказы, где присутствует товар X". Например, если поставки товара X прекратились и надо уведомить заказчиков об этом. В случае хранения сериализованных данных вас ждут пляски с бубном... В первом варианте - простейший SELECT.

Scratch

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

например глупая менеджер вместо кнопки "отклчить товар" нажала кнопку "удалить товар" и во всех заказах при join'e пошли позиции пиздой где присутствовал этот товар.
 
еще доводы?

phpdude

например глупая менеджер вместо кнопки "отклчить товар" нажала кнопку "удалить товар" и во всех заказах при join'e пошли позиции пиздой где присутствовал этот товар.

это решается внешним ключом с ограничением

phpdude

Scratch

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

например глупая менеджер вместо кнопки "отклчить товар" нажала кнопку "удалить товар" и во всех заказах при join'e пошли позиции пиздой где присутствовал этот товар.

Ваш пример говорит о глупом программисте, а не о глупом менеджере. Проверку целостности данных для исключения появления товаров-"орфанов" в заказах никто не отменял, и, кстати, такая проверка опять-таки гораздо проще выполняется при хранении данных в несериализованном виде - простейший SELECT для проверки существование товара в заказах перед удалением и сообщение для глупого менеджера от умного программиста.
 
Сериализацию вполне уместно применять для полей, являющихся "описательными" - полей хранения каких-либо вспомогательных данных, извлекаемых для одной записи. Но хранить в сериализованном виде индексные поля выйдет себе дороже.
 
Могу кстати привести и пример реальных PHP приложений, где применяются 2 вышеуказанных подхода. CMS Joomla и популярные CCK K2 и ZOO. В первом элементы для создания приложений хранятся в классическом "реляционном" виде, во втором приложении - в виде сериализованных данных в XML. Сравнивались данные по производительности и, несмотря на бОльшее количество запросов к MySQL для получения нужной схемы данных, первый компонент работает быстрее, чем тот, в котором производится десериализация на лету. И по удобству схемы построения данных для дальнейшей разработки первый компонент явно лидирует: количество сторонних дополнений для классической схемы на порядки больше.

Scratch

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

Scratch

Ваш пример говорит о глупом программисте

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

phpdude, даже я получил от тебя имайл))

md5, да ты ваще сучка, постоянно их получаешь )) надо бы починить это блеядьство xD

phpdude, лучше новый пыха.ру
с блекджеками и шлюхами
 
скоро новый логотип нам сделают, кстати, хороший :)
мы пока думаем
склоняемся к стилю стимпанка и машинариума

phpdude

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

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

оффтоп: я просто хотел скзаать что оба метода если влоб имеют недостатки, вот и все, ничего личного. маста хорошо подметил что можно одним внешним ключем решить эту проблему.

И я говорю то же самое :) Можно и ключем, просто выводить осмысленное информационное сообщение вместо сообщения о нарушении целостности (или не выводить никакого) удобнее, если делать запрос.