Как добавить товар в корзину?

Question

[pe4eHbE]

привет всем. Подскажите как правильно создать таблицу для корзины и оформления готового заказа?
Я создал много таблиц под разные товары.:
Например, Кулеры - prntscr.com/77eoqd
Видеокарты - prntscr.com/77eoy2
Как видно, у всех таблиц разное название полей.
Когда я нажимаю на "кулеры" - Купить, то кулер попадает в корзину, а там смогу увеличить кол-во продукта. И так с многими товарами. Когда нажимаю на "оформить заказ", то данные этих товаров ( название, количество, цена) вносятся в таблицу.
И надо вывести потом информацию о заказанных товарах - типа отчет. название товара, цена, количество. И так для каждого товара.
Я не знаю какие конкретно создать таблицы, какие поля для корзины, связывать ли? Ведь у меня не одна таблица "Товары", где есть 5 полей статических и меняется только название.

Answer 1

[Станислав Макаров]

Вам уже посоветовали использовать json, я попробую дать более общую рекомендацию. У вас стандартная для вашей предметной области проблема - отсутствие единой схемы данных, у вас имеющихся. Очень редко в работающем приложении кто-либо меняет схему "на ходу" - т.е. в 99% случаев схема (по кр. мере логическая) проектируется вместе с приложением. Новая версия приложения - новая схема (при необходимости, конечно). Таким образом, ваша задача диктует вам необходимость работать с ЧАСТЬЮ ваших данных без использования схемы. Согласитесь, это не очень гибко - заводить новую таблицу под каждый вид товара, коих огромное количество может быть. Самое главное, новые товары приходят каждый день, и каждый день добавлять таблицы - с ума сойдешь. И совершенно непонятно, как при этом разрабатывать SQL-запросы на выборку, учитывая все новые и новые таблицы.
Т.о., часть данных вам лучше хранить иначе, а именно атрибуты ваших товаров. Тут подхода два: это либо полуструктурированные данные (semistructured), т.е. XML или JSON, либо EAV модель. Последняя является классическим выходом из ситуации при использовании реляционных баз данных, однако т.к. она по определению идет в разрез с реляционной структурой данных - это все по сути большой костыль. Сегодня все чаще рекомендуют первый вариант, т.к. во-первых многие современные РСУБД поддерживают JSON или XML типы данных, причем даже с возможностями валидации и выборки (а если и нет - BLOB всегда поможет), а во-вторых под каталог товаров можно использовать любую документную базу данных, которая кстати еще и лучше подойдет по специфике нагрузки на каталог (очень много чтения и мало записи, целостность не особо нужна - шардинг будет без особых проблем).
Итого:
1) понимаете, почему не все данные не всегда получается уложить в фиксированную схему
2) выбираете себе подходящее решение из перечисленных, помня, что можно (и нужно!) часть данных хранить в нормализованном виде, а часть - не получится.
3) поиск и выборка по ненормализованным данным рассматривается как отдельная задача
P.S. вот как раз таки в корзину достаточно класть ID товара и его количество, что отлично уложится в реляционную схему. А для этого таблица товаров одна должна быть.

Comments

[pe4eHbE]

Да. Но есть 1 замечание "Согласитесь, это не очень гибко - заводить новую таблицу под каждый вид товара, коих огромное количество может быть. Самое главное, новые товары приходят каждый день, и каждый день добавлять таблицы - с ума сойдешь. И совершенно непонятно, как при этом разрабатывать SQL-запросы на выборку, учитывая все новые и новые таблицы."
Я не добавляю новые таблицы, когда регистрирую новую запись нужной мне категории. У меня БД содержит фиксированные таблицы (Кулера, Процессоры, Видеокарты и т.д. В общем, комплектующие). В этих таблицах есть поля, которые в первом посте.
Как происходит добавление? Я перехожу на нужную мне страницу(Видеокарты), нажимаю на "добавить" - выводятся поля для ввода информации. Как я говорил, их около 10+ (Наличие, производитель, память и т.д)
Вот в этом и проблема с корзиной и выводом готового заказа.

[Станислав Макаров]

Разумеется я имел в виду добавление новой категории со своим набором характеристик, а не отдельного товара. Так или иначе, если вы хотите хранить заказы в реляционном виде, таблицу товаров у вас должна быть одна.

[pe4eHbE]

Станислав Макаров: я вроде бы придумал как организовать добавление в корзину.
У меня в корзине такие поля - CartID, ItemID, Quantity.
На сайте есть категории, я захожу на определенную категорию и при клике "Выбрать или купить" передаю в ItemID айди товара из таблицы Видеокарты, например. Перехожу на "Процессоры" - передаю айди из таблицы Процессоры.... Такой же вариант подойдет? Но вот вывод информации для отчета - будет проблематичным(я так думаю)?? В ItemID же будет попадать ID из разных таблиц...

[pe4eHbE]

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

[Станислав Макаров]

@Pe4enie
> Но вот вывод информации для отчета - будет проблематичным(я так думаю)?? В ItemID же будет попадать ID из разных таблиц...
Да, черт возьми, вот поэтому я в последний раз вам советую одну таблицу товаров с каким-либо JSON-овским полем, где будут храниться все характеристики конкретного вида товара. Вы вообще читали ответы? Вам объясняют, что вы ни одного запроса толком не сможете сделать, а если и сможете (SELECT из всех ваших таблиц), то как вы будете новые категории добавлять? Вот просто напишите сейчас пару запросов и прикиньте что у вас ситуация с необходимостью добавить новый тип товара.
> Да, я упёртый ибо заново пересоздавать таблицы не хочется.
> На скорую руку хочется сейчас сделать ибо во времени ограничен.
Подобные критерии нужно указывать в начале вопроса. Многие тут во времени или в чем-то еще ограничены, и вам дают советы, чтобы у вас седина потом появилась от поддержки такой системы, а если это лаба а не система, и вам "не хочется пересоздавать таблицы" - зачем на тостер пришли?
Если вы в продакшене это делаете - мне вас искренне жаль, а если в учебе - нахрена, простите, вы тогда учитесь, если не пытаетесь перенять опыт других? "Кодить" учитесь?

[Anchor00]

Станислав Макаров: Кстати говоря, MySQL ввели в тестовом релизе тип данных JSON mysqlserverteam.com/json-labs-release-native-json-... Станислав, такой вопрос, как считаете. Напр. есть 1,5-2тыс товаров, определенного типа(тип:майки к примеру), и у него надо удалить/изменить/добавить Атрибут Цвет. Получается нужно: 1)считать ВСЕ 1,5-2тыс товаров 2)десериализовать каждый JSON/XML кусок текста 3)удалить/изменить/добавить атрибут 4)Записать ВСЕ 1,5-2тыс. товаров. Это слишком дорогая операция? Или есть какие-то способы обойти подобный гемор.

[Станислав Макаров]

Anchor00, я согласен с вами, что такая операция по крайней мере выглядит дорогой. Правда я не уверен, что она будет сильно дешевле в реляционной модели (т.е. если бы цвет был обычной колонкой в таблице). В больших БД с классическим хранением записей друг за другом операции добавления колонок могут занимать довольно приличное время (column-store базы не в счет). Во-вторых, десериализация, о которой вы говорите - вещь необходимая только в случае, если именно вы, на уровне приложения, добавляете/изменяете в каждом документе (товаре) атрибут Цвет. Если же вы попросите сделать это вашу СУБД, она, вероятно, справится с этим лучше. Например, предположу, что MongoDB не будет десериализовывать документы из BSON-а (bsonspec.org), в котором она их хранит, в JSON, она добавит атрибут так, как ей это удобно, с минимальными издержками. Аналогично и с XML-документами. Вероятно это будет медленнее, чем если бы у нас сразу была колонка Цвет, но это закономерная плата за гибкость и отсутствие схемы. Вывод из сказанного: прежде всего нужно максимально пользоваться возможностями СУБД, в т.ч. языком запросов. Поддержка JSON и XML в том и заключается, что это для СУБД уже не просто строки, а таки данные с определенной структурой. Ну и конечно если Mysql или Postgres вам дают лишь доп. набор функций для работы с JSON и небольшие оптимизации по производительности, то документно-ориентированные СУБД будут поддерживать такие данные нативно, и где-то выигрывать в производительности (хотя должен сказать, что видел наборы тестов, утеверждающих что PostgreSQL не особо отстает от Монги в хранении json-документов, так что этот вопрос требует исследования).

[Станислав Макаров]

Anchor00 вот кстати эти самые тесты: www.enterprisedb.com/postgres-plus-edb-blog/marc-l... . Ну это отдельный холивар, основную мысль вы поняли)

Answer 2

[Алексей Кулаков]

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

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

Есть несколько Нормальных форм для баз данных. Каждая из них убирает некую избыточность. Минимум база должна соответствовать 3-ей нормальной форме, почитайте про 1НФ, 2НФ, 3НФ и 3,5НФ (или нормальная форма Бойса-Кодда или НФБК). Иногда проводят денормализацию, но для этого нужно понимать для чего и в каких случаях это делается.

Теперь о вашей структуре таблиц.
В вашем случае есть некий товар, есть категории (или группы, ваши видеокарты, кулеры и бог знает что еще) товаров. Вот вам две таблицы - Товар, Категория товара. Ну и связь между ними конечно же один ко многим так, что одной категории соответствует множество товаров, но один товар всегда соответствует одной категории. Если товар может быть в нескольких категориях (связь многие ко многим), то это делается через дополнительную таблицу. Итого имеем удобство добавления новых категорий товаров - добавляем новую категорию и при добавлении товара указываем к какой категории он относится. какие-нибудь теги тоже можно по такой же схеме организовать.

Далее, нужен нам заказ, делаем таблицу Заказ с полями кто заказал, когда заказал, иные примечания и поля, но не что заказал. Табличная часть заказа должна быть в отдельной таблице, где есть ссылка на товар (одну таблицу а не как у вас сейчас), количество, иные поля, и ссылка на заказ к которому та или иная позиция относится.

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

Свойства товаров, как сказали, можно хранить в json или в xml, но это не удобно для фильтров каких-нибудь да и добавлять/редактировать значения свойств как-то не удобно - загрузи, десериализуй, измени/добавь, сериализуй и сохрани. Если они никогда не меняются и по ним нет поиска, то я бы сохранил как сериализованный в json или xml объект. Иначе тоже через таблицы, связанные с товаром связью. тут можно накрутить много, и группы свойств для каждой категории и всякое другое.

Answer 3

[LittleFatNinja]

таблица корзины будет содержать id, кол-во и категорию товара