Добрый день. Где-то видел подобную тему, но сейчас не нашел. Задача такая. Надо в MySQL хранить заказы покупателей в интернет-магазине. Рассматриваю два варианта. Записывать в БД каждую позицию купленного товара (естественно с отметкой принадлежности к какому либо заказу.) Или для каждого заказа вставлять одну запись где и будет храниться массив со всеми купленными товарами. Хранить массив мне показалось лучше. В связи с этим нашел статейку как это сделать - http://ruseller.com/lessons.php?rub=37&id=699
Вопрос 1 как лучше хранить?
Вопрос 2 верить ли указанной статье?
новые сообщения
ответы на мои сообщения
избранное
скрытые темы
случайный топик
открыть всё в новых вкладках
Форум → Разработка → Базы данных → Хранение массивов в БД
Хранение массивов в БД
Страницы: ← Следующая страница →
-
Сообщения:
236
Репутация:
N
Группа:
Кто попало
-
Сообщения:
2532
Репутация:
N
Группа:
Джедаи
22 апреля 2011 г. 15:46, спустя 1 час 2 минуты 59 секунд
серилизовать и хранитьСпустя 24 сек.Еще в json можно -
Сообщения:
3244
Репутация:
N
Группа:
Джедаи
22 апреля 2011 г. 15:46, спустя 12 секунд
как хранить зависит от того что ты собираешься потом с этими данными делать, какие нужны выборкине всё полезно, что в swap полезло -
Сообщения:
2284
Репутация:
N
Группа:
Адекваты
22 апреля 2011 г. 15:52, спустя 5 минут 57 секунд
smv, это не лучший вариант. Причины:
1. Если тебе понадобится некая статистика аль ещё чего-нить подобное, то ты хрен её получишь нормальными методами.
2. Если удаляешь из базы некий товар, то в твоем случае в старом заказе будет "дырка". А в случае первого твоего варианта ты можешь при удалении товара из базы просто сделать некую отметку или прочее со всеми заказами, которые были на этот товар.
Нужно это для случая, если, к примеру, один товар просто удален из базы, так как ты передумал им торговать, другой удален так как больше не выпускается. А третий товар удален, так как менеджер дятел.
В общем, в любом случае если будет стоять некая отметка о причине удаления товара, то вполне возможно в заказе это отметить, или же даже банально сохранить только наименование удаленного товара в заказах.
Хотя, если магазин мелкий, то делай как тебе удобней. А хранить массив в БД удобно в помощью функции serialized(). -
Сообщения:
236
Репутация:
N
Группа:
Кто попало
22 апреля 2011 г. 15:57, спустя 4 минуты 24 секунды
серилизовать и хранить
Спасибокак хранить зависит от того что ты собираешься потом с этими данными делать, какие нужны выборки
По каждому заказу выбираю массив с id товаров. Выбираю товары в соответствии с id их цену и отправляю по почте.Спустя 116 сек.
smv, это не лучший вариант. Причины:
1. Если тебе понадобится некая статистика аль ещё чего-нить подобное, то ты хрен её получишь нормальными методами.
2. Если удаляешь из базы некий товар, то в твоем случае в старом заказе будет "дырка". А в случае первого твоего варианта ты можешь при удалении товара из базы просто сделать некую отметку или прочее со всеми заказами, которые были на этот товар.
Нужно это для случая, если, к примеру, один товар просто удален из базы, так как ты передумал им торговать, другой удален так как больше не выпускается. А третий товар удален, так как менеджер дятел.
В общем, в любом случае если будет стоять некая отметка о причине удаления товара, то вполне возможно в заказе это отметить, или же даже банально сохранить только наименование удаленного товара в заказах.
Хотя, если магазин мелкий, то делай как тебе удобней. А хранить массив в БД удобно в помощью функции serialized().
О спасибо… будет над чем подумать. -
Сообщения:
6480
Репутация:
N
Группа:
Джедаи
22 апреля 2011 г. 16:20, спустя 22 минуты 57 секунд
В связи с этим нашел статейку как это сделать - http://ruseller.com/lessons.php?rub=37&id=699
Частная коллекция качественных материалов для тех, кто делает сайты
ложь, пиздешь и провокация -
Сообщения:
5
Репутация:
N
Группа:
Кто попало
24 мая 2011 г. 2:35, спустя 31 день 10 часов 15 минут
Классический вариант в виде таблицы id заказа - id товара лучше. Подумайте, например, над простой задачей - "вывести все заказы, где присутствует товар X". Например, если поставки товара X прекратились и надо уведомить заказчиков об этом. В случае хранения сериализованных данных вас ждут пляски с бубном… В первом варианте - простейший SELECT.
-
Сообщения:
26646
Репутация:
N
Группа:
в ухо
24 мая 2011 г. 2:48, спустя 13 минут 20 секунд
Например, если поставки товара X прекратились и надо уведомить заказчиков об этом. В случае хранения сериализованных данных вас ждут пляски с бубном… В первом варианте - простейший SELECT.
например глупая менеджер вместо кнопки "отклчить товар" нажала кнопку "удалить товар" и во всех заказах при join'e пошли позиции пиздой где присутствовал этот товар.
еще доводы?Сапожник без сапог -
Сообщения:
3244
Репутация:
N
Группа:
Джедаи
24 мая 2011 г. 7:55, спустя 5 часов 7 минут 7 секунд
например глупая менеджер вместо кнопки "отклчить товар" нажала кнопку "удалить товар" и во всех заказах при join'e пошли позиции пиздой где присутствовал этот товар.
это решается внешним ключом с ограничениемне всё полезно, что в swap полезло -
Сообщения:
5
Репутация:
N
Группа:
Кто попало
24 мая 2011 г. 23:38, спустя 15 часов 42 минуты 54 секунды
Например, если поставки товара X прекратились и надо уведомить заказчиков об этом. В случае хранения сериализованных данных вас ждут пляски с бубном… В первом варианте - простейший SELECT.
например глупая менеджер вместо кнопки "отклчить товар" нажала кнопку "удалить товар" и во всех заказах при join'e пошли позиции пиздой где присутствовал этот товар.
Ваш пример говорит о глупом программисте, а не о глупом менеджере. Проверку целостности данных для исключения появления товаров-"орфанов" в заказах никто не отменял, и, кстати, такая проверка опять-таки гораздо проще выполняется при хранении данных в несериализованном виде - простейший SELECT для проверки существование товара в заказах перед удалением и сообщение для глупого менеджера от умного программиста.
Сериализацию вполне уместно применять для полей, являющихся "описательными" - полей хранения каких-либо вспомогательных данных, извлекаемых для одной записи. Но хранить в сериализованном виде индексные поля выйдет себе дороже.
Могу кстати привести и пример реальных PHP приложений, где применяются 2 вышеуказанных подхода. CMS Joomla и популярные CCK K2 и ZOO. В первом элементы для создания приложений хранятся в классическом "реляционном" виде, во втором приложении - в виде сериализованных данных в XML. Сравнивались данные по производительности и, несмотря на бОльшее количество запросов к MySQL для получения нужной схемы данных, первый компонент работает быстрее, чем тот, в котором производится десериализация на лету. И по удобству схемы построения данных для дальнейшей разработки первый компонент явно лидирует: количество сторонних дополнений для классической схемы на порядки больше. -
Сообщения:
26646
Репутация:
N
Группа:
в ухо
24 мая 2011 г. 23:54, спустя 15 минут 19 секунд
Сравнивались данные по производительности и, несмотря на бОльшее количество запросов к MySQL для получения нужной схемы данных, первый компонент работает быстрее, чем тот, в котором производится десериализация на лету.
Ваш пример говорит о глупом программисте
дае долбоебу очевидно что сериализация работает в сотни раз быстрее запросов в базу. ну хотя учитывая долбоебность программистов жумлы - не удивлюсь что даже сериализацию они испоганили настолько насколько смогли.
оффтоп: я просто хотел скзаать что оба метода если влоб имеют недостатки, вот и все, ничего личного. маста хорошо подметил что можно одним внешним ключем решить эту проблему.Спустя 23 сек.master, маста, ты получил от меня имайл?Сапожник без сапог -
Сообщения:
11960
Репутация:
N
Группа:
в ухо
25 мая 2011 г. 0:00, спустя 6 минут 15 секунд
phpdude, даже я получил от тебя имайл))все умрут, а я изумруд -
Сообщения:
26646
Репутация:
N
Группа:
в ухо
25 мая 2011 г. 0:03, спустя 3 минуты
md5, да ты ваще сучка, постоянно их получаешь )) надо бы починить это блеядьство xDСапожник без сапог
-
Сообщения:
11960
Репутация:
N
Группа:
в ухо
25 мая 2011 г. 0:23, спустя 20 минут 30 секунд
phpdude, лучше новый пыха.ру
с блекджеками и шлюхами
скоро новый логотип нам сделают, кстати, хороший :)
мы пока думаем
склоняемся к стилю стимпанка и машинариумавсе умрут, а я изумруд -
Сообщения:
5
Репутация:
N
Группа:
Кто попало
25 мая 2011 г. 0:32, спустя 8 минут 42 секунды
дае долбоебу очевидно что сериализация работает в сотни раз быстрее запросов в базу. ну хотя учитывая долбоебность программистов жумлы - не удивлюсь что даже сериализацию они испоганили настолько насколько смогли.
Сериализация будет работать быстрее для извлечения данных для одной единственной записи или до определенного порога, после которого JOIN будет быстрее. Программисты, которые писали оба приложения - не самые худшие. Второе приложение проигрывает в производительности именно в случае выборки больших объемов данных, то есть при достижении определенного числа записей, как и было сказано ранее.оффтоп: я просто хотел скзаать что оба метода если влоб имеют недостатки, вот и все, ничего личного. маста хорошо подметил что можно одним внешним ключем решить эту проблему.
И я говорю то же самое :) Можно и ключем, просто выводить осмысленное информационное сообщение вместо сообщения о нарушении целостности (или не выводить никакого) удобнее, если делать запрос.
Страницы: ← Следующая страница →
Пожалуйста, авторизуйтесь, чтобы написать комментарий!