Одна или несколько строк MySQL? (корзина)

Question

Одна или несколько строк MySQL? (корзина)

0

В настоящее время я создаю собственный сайт электронной коммерции (в php, но это не актуально для этого вопроса).

Я только что создал корзину покупок и не могу решить между двумя следующими вариантами:

вариант 1:
Таблица корзин:

ID
Пользователь
элементы

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

Этот формат уже используется в корзине на основе cookie для пользователей без регистрации, поэтому синтаксический анализ поля элементов не представляет проблемы.

вариант 2:
Таблица Basket_items:

ID
Пользователь
элемент
количество

В этой опции у меня будет одна строка за элемент в корзине.

вариант 3:
предложить лучшую идею.

вывод

Обе эти опции одинаково легко реализуются, поэтому возникает вопрос, который будет более эффективным/удобным для обновления корзины.

Спасибо за любые ответы, Нико

Nico Burns 06 дек. 2009, в 01:33

Источник

Теги:

mysql

sql

e-commerce

6 ответов

2

Используйте вариант 2 - вы не можете реально поддерживать изменения в корзине покупок, используя вариант 1, или сообщить об этом.

OMG Ponies 05 дек. 2009, в 22:19

2

ВАРИАНТ 3

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

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

корзины

ID
user_id

basket_items

ID
basket_id
item_id
количество

Corey Ballou 05 дек. 2009, в 21:55

1

Это не нужно Предполагая, что у пользователя нет нескольких корзин.
Gary Green 05 дек. 2009, в 23:52
0

@Gary - Создав корзину покупок с нуля и просмотрев множество систем с открытым исходным кодом, я могу убедиться, что это НЕ плохой выбор, чтобы защитить вашу корзину в будущем, независимо от того, насколько просто вы ее создали. Я не обращаю внимания на ваш -1, потому что он не был хорошо продуман.
Corey Ballou 05 дек. 2009, в 23:57
1

Мне кажется ненужным - добавь сложности в систему. Кроме того, не составит труда перевести одну из систем в эту систему, если в будущем потребуется несколько корзин для каждого пользователя.
Nico Burns 06 дек. 2009, в 00:02
0

+1, чтобы восстановить вас от -1 :-). Я бы сказал, что вы всегда можете выполнить рефакторинг, когда вам нужно иметь несколько тележек.
Jean Barmash 06 дек. 2009, в 00:04
0

+1 за правильно нормированную модель данных
OMG Ponies 06 дек. 2009, в 00:08
0

Мои -1 пальцы были немного поспешными и, возможно, несправедливыми, однако я никогда не сталкивался с сайтом, где у пользователей есть несколько корзин. Я не вижу смысла советовать иметь более сложную структуру данных, которая, скорее всего, никогда не будет использоваться.
Gary Green 06 дек. 2009, в 00:09
1

@ Гэри: Если хотите, вы можете изменить свое отрицательное мнение, но учтите, что история покупок с течением времени будет иметь несколько «корзин». Корзина - это просто синоним заказа.
OMG Ponies 06 дек. 2009, в 00:11
0

@OMG - спасибо за признание нормализации. Я подумывал упомянуть 3NF или BCNF, но решил, что это выходит за рамки ответа. Думаю, мне следовало поднять это, чтобы избежать моего первоначального понижения: P
Corey Ballou 07 дек. 2009, в 17:59

Показать ещё 6 комментариев

1

Вариант 1 потребует, чтобы вы сериализовали данные в столбце элементов, которые, как правило, не одобряются по причинам сложности и производительности.

Вы используете БД для его возможностей связывания, поэтому можете использовать их. Ваша таблица cart_items должна работать очень красиво. Таким образом, каждая тележка может указывать на пользователя, и все предметы в корзине могут указывать на корзину.

Chuck Vose 05 дек. 2009, в 21:00

0

Варианты 2 являются предпочтительным вариантом.

"item_id" может быть идентификатором таблицы, в которой хранятся все элементы (таблица сохранения) и где для этого элемента доступно полное описание и другая информация. Но я бы добавил к этой корзине ценник для каждого элемента, и часто имеет смысл добавить в эту корзину также идентификатор сеанса id/md5. Таким образом, строка запроса SQL для PHP для создания такой таблицы может быть примерно такой:

   $sql="CREATE TABLE ".$table_prefix."Basket (
   id int(11) NOT NULL auto_increment,
   sid varchar(50) default NULL,
   item_id int(10) default NULL,
   quantity int(10) default 1,
   price varchar(10) default NULL,
   PRIMARY KEY(id)
) $collate_charset;";

$collate_charset: что-то вроде $collate_charset="DEFAULT CHARACTER SET utf8";

$table_prefix: часто полезно иметь префикс для таблиц типа $table_prefix="myshop_";

С такой таблицей вы можете воспользоваться функциями SQL, такими как "Sum", чтобы получить быстрый промежуточный итог пользователю или всем пользователям без большого количества кода ( "Выберите сумму (количество * цена) WHERE sid= '1234'" ). Если эта корзина также предназначена для "гостей", вам нужна другая таблица, в которой хранится идентификатор сеанса и дата создания, поэтому вы можете регулярно очищать корзину от неиспользуемых записей.

devarni 07 дек. 2009, в 15:20

0

Вариант 2. Это лучший вариант и обеспечивает хорошую нормализацию данных. Это уступит место возможным будущим расширенным выборам и фильтрации корзины пользователей.

Gary Green 05 дек. 2009, в 21:40

Ещё вопросы

Это не нужно Предполагая, что у пользователя нет нескольких корзин.
@Gary - Создав корзину покупок с нуля и просмотрев множество систем с открытым исходным кодом, я могу убедиться, что это НЕ плохой выбор, чтобы защитить вашу корзину в будущем, независимо от того, насколько просто вы ее создали. Я не обращаю внимания на ваш -1, потому что он не был хорошо продуман.
Мне кажется ненужным - добавь сложности в систему. Кроме того, не составит труда перевести одну из систем в эту систему, если в будущем потребуется несколько корзин для каждого пользователя.
+1, чтобы восстановить вас от -1 :-). Я бы сказал, что вы всегда можете выполнить рефакторинг, когда вам нужно иметь несколько тележек.
+1 за правильно нормированную модель данных
Мои -1 пальцы были немного поспешными и, возможно, несправедливыми, однако я никогда не сталкивался с сайтом, где у пользователей есть несколько корзин. Я не вижу смысла советовать иметь более сложную структуру данных, которая, скорее всего, никогда не будет использоваться.
@ Гэри: Если хотите, вы можете изменить свое отрицательное мнение, но учтите, что история покупок с течением времени будет иметь несколько «корзин». Корзина - это просто синоним заказа.
@OMG - спасибо за признание нормализации. Я подумывал упомянуть 3NF или BCNF, но решил, что это выходит за рамки ответа. Думаю, мне следовало поднять это, чтобы избежать моего первоначального понижения: P

Jean Barmash · Accepted Answer · 2009-12-05T22-00-00.000Z

Вариант 2 - путь. Сохранение всех элементов и количества в поле элементов (вариант 1) означает, что вы идете против реляционного характера MySQL. Вам нужно будет определить формат и проанализировать его с помощью опции 1, дополнительного кода, который у вас нет, с параметром 2. Кроме того, с Вариантом 2 вы сможете делать другие вещи проще, например, вычислять итоговые значения, суммы доставки и т.д., а также отчетность о проданных предметах (просто простой запрос).

Конечно, если бы я писал это, я также спросил бы, есть ли библиотека для этого - зачем изобретать такие общие функции, как корзина покупок. Я не из мира PHP, поэтому я не знаю, какие есть варианты, но я уверен, что вы должны снова использовать его. Поэтому, в конечном счете, я бы посоветовал вам выбрать вариант 3 - не реализовывать его самостоятельно, если вы его избегаете: -)

Хорошие моменты, ваш вариант 3, конечно, очень разумная идея, но я странный человек, и я решил, что лучше написать свою собственную систему, чем научиться настраивать код, который я не понимаю. Я думаю, что я, вероятно, пойду с вариантом 2, хотя мне не нужно было бы писать код для разбора варианта 1, так как это уже написано - я использую его для хранения элементов корзины в cookie для пользователей, которые не вошли в систему. Насколько я могу судить, для системы на основе файлов cookie нет другого варианта.
Вы думаете, что есть библиотека для модели данных ?!
OMG - не библиотека для модели данных, а модуль, позволяющий интегрировать этот тип функциональности в другую систему, включая модель данных, бизнес-логику и некоторый пользовательский интерфейс.