Стоит задача , нужно как-то хранить описание и характеристику товаров в бд , при том что у разных товаров разной длинны характеристика и описание ? остановился на том , что можно сериализовать массив (с произвольной длинной и кол-вом элементов , как мне и нужно) в строку и уже эту строку пихать в бд.. Так вот , насколько это вообще правильно и есть ли альтернатива этому ? как хранят описание и характеристики популярные интернет-магазины ?
Хранить такие данные в сериализованом массиве вообще не тру. Для таких задач либо создаются три таблицы:
- Товары
- Характеристики
- Значение характеристики для товаров
либо используются NoSQL базы данных. А выбор из этих подходов стоит делать исходя из требований и нагрузок Вашей системы.
Ну по-разному хранят... Обычно это куча связанных таблиц. Например, есть таблицы "Товары" и "Свойства". Связь "многие-ко-многим", т.е. есть еще результирующая таблица ТоварыСвойства, которая выглядит как-то так: id, id_товара, id_свойства. И таких таблиц в БД пруд пруди... Как хочешь так и хранишь.
ну а есть ли смысл это делать если у меня не больше 100-200 товаров во всем интернет-магазине , но они разные , и на категорию приходится 10-20 товаров ? я ж помру пока сделаю эти все таблицы со всеми свойствами
NoName_0: Ну смотря что вы хотите. Вам никто не запрещает товары в Excel хранить, а на сервере к файлу обращаться для забора информации. Хозяин-барин, но большинство интернет-магазинов хранит данные в БД в разделенном виде, что упрощает им работу по поиску товаров и дает гибкость при построении выборок.
NoName_0: Нет, что вы) Для категорий создается одна отдельная таблица "Категории", содержащая в себе, например, id_категории, описание_категории и id_parent_категории, если предусматривается вложенность категорий (поле нужно для построения дерева категорий). Есть таблица "Товары". И тут нужно думать "Может ли быть товар в нескольких категориях одновременно"? Если может, то создается таблица связей ТоварыКатегории, если нет, то создается поле "категория" в таблице "Товары"... Вообще, хорошо спроектированная база данных избавит вас от головной боли при масштабировании (расширении бизнеса). Вообще, то, что вы спрашиваете - это основы проектирования баз данных. Вам или книжку почитать нужно, или искать другой вариант хранения данных. Но общепринятая практика такова, как я описал выше.
дада, конечно . я думал , сериализовывать в строку или в json .. и я действительно хочу сделать в json ... вопрос в другом , насколько это нормально , в реляционной бд хранить сериализованые массивы ?
NoName_0: тогда делайте так, как вам проще. Но я бы на вашем месте подумал на пару шагов вперед - возможно придется как-то работать с характеристиками. И вот тогда придется все переделывать.
Простой
Простой
