ФорумРазработкаБазы данных → Хранение массивов в БД

Хранение массивов в БД

  • smv

    Сообщения: 236 Репутация: N Группа: Кто попало

    Spritz 22 апреля 2011 г. 6:43

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

    Вопрос 1 как лучше хранить?
    Вопрос 2 верить ли указанной статье?
  • Troy

    Сообщения: 2532 Репутация: N Группа: Джедаи

    Spritz 22 апреля 2011 г. 7:46, спустя 1 час 2 минуты 59 секунд

    серилизовать и хранить
    Спустя 24 сек.
    Еще в json можно
  • master

    Сообщения: 3236 Репутация: N Группа: Джедаи

    Spritz 22 апреля 2011 г. 7:46, спустя 12 секунд

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

    Сообщения: 2284 Репутация: N Группа: Адекваты

    Spritz 22 апреля 2011 г. 7:52, спустя 5 минут 57 секунд

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

    Хотя, если магазин мелкий, то делай как тебе удобней. А хранить массив в БД удобно в помощью функции serialized().
  • smv

    Сообщения: 236 Репутация: N Группа: Кто попало

    Spritz 22 апреля 2011 г. 7:57, спустя 4 минуты 24 секунды

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

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

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

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

    Хотя, если магазин мелкий, то делай как тебе удобней. А хранить массив в БД удобно в помощью функции serialized().


    О спасибо… будет над чем подумать.
  • Абырвалг

    Сообщения: 6476 Репутация: N Группа: Джедаи

    Spritz 22 апреля 2011 г. 8:20, спустя 22 минуты 57 секунд

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

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

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

    Сообщения: 5 Репутация: N Группа: Кто попало

    Spritz 23 мая 2011 г. 18:35, спустя 31 день 10 часов 15 минут

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

    Сообщения: 26624 Репутация: N Группа: в ухо

    Spritz 23 мая 2011 г. 18:48, спустя 13 минут 20 секунд

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

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

    еще доводы?
    Сапожник без сапог
  • master

    Сообщения: 3236 Репутация: N Группа: Джедаи

    Spritz 23 мая 2011 г. 23:55, спустя 5 часов 7 минут 7 секунд

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

    это решается внешним ключом с ограничением
    не всё полезно, что в swap полезло
  • Scratch

    Сообщения: 5 Репутация: N Группа: Кто попало

    Spritz 24 мая 2011 г. 15:38, спустя 15 часов 42 минуты 54 секунды


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

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


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

    Сериализацию вполне уместно применять для полей, являющихся "описательными" - полей хранения каких-либо вспомогательных данных, извлекаемых для одной записи. Но хранить в сериализованном виде индексные поля выйдет себе дороже.

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

    Сообщения: 26624 Репутация: N Группа: в ухо

    Spritz 24 мая 2011 г. 15:54, спустя 15 минут 19 секунд

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

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

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

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

    Сообщения: 11949 Репутация: N Группа: в ухо

    Spritz 24 мая 2011 г. 16:00, спустя 6 минут 15 секунд

    phpdude, даже я получил от тебя имайл))
    все умрут, а я изумруд
  • phpdude

    Сообщения: 26624 Репутация: N Группа: в ухо

    Spritz 24 мая 2011 г. 16:03, спустя 3 минуты

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

    Сообщения: 11949 Репутация: N Группа: в ухо

    Spritz 24 мая 2011 г. 16:23, спустя 20 минут 30 секунд

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

    скоро новый логотип нам сделают, кстати, хороший :)
    мы пока думаем
    склоняемся к стилю стимпанка и машинариума
    все умрут, а я изумруд
  • Scratch

    Сообщения: 5 Репутация: N Группа: Кто попало

    Spritz 24 мая 2011 г. 16:32, спустя 8 минут 42 секунды


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

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

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

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

Пожалуйста, авторизуйтесь, чтобы написать комментарий!