БД и работу с ней для «корзины товаров» на Eloquent Laravel как лучше реализовать?

Question

[Роман]

Здравствуйте, мне нужно сделать что-то вроде "корзины товаров". Помогите пожалуйста, советом. Есть таблицы:

users
    id - integer
    email - string

profile
    id - integer
    user_id - integer (внешний ключ к users) 
    name - string 

products
    id - integer
    description - string

korzina
    id - integer
    kolichestvo - integer
    products_id - integer (внешний ключ к products) 
    user_id - integer (внешний ключ к users)

1. Я правильно сделал структуру? Или может внешний ключ из корзины лучше сделать к профайлу? Или что тут по структуре можно посоветовать?

2. Мне нужно из вьюхи профайла управлять этой корзиной (товары будут отображены там же) - т.е. единичный чекбокс на каждом товаре и поле с количеством - мне лучше сделать отдельный контроллер для корзины, или лучше сделать это в контроллере профайла?

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

4. Любые ваши замечания и советы :)

Спасибо.

Comments

[JhaoDa]

Я надеюсь, что user_id в корзине может быть null? Ибо если для заказа чего-либо надо регистрироваться, то такой магазин обречён.

[Роман]

JhaoDa, надо регистрироваться :) иначе как потом сопровождать товар?

[JhaoDa]

procode, чудесный бизнес-план. Удачи.

Answer 1

[Виталий Юшкевич]

Чем профиль отличается от пользователя?
Корзина привязана должна быть к пользователю или профилю?
Может ли быть у одного человека несколько корзин и функционал переключения между ними?
Есть гипотеза, что "перевод" лучше подходит, чем "транслит". Наглядно cart лучше чем korzina.

В зависимости от ответов выше, могут быть нюансы, но основные идеи:
- Корзина базовая сущность. Если связь с владельцем 1-1, то вполне можно ключ можно дублировать. В ней неплохо хранить общую информацию - общую сумму, вес
- Товары привязываются к корзине отдельной таблицей, либо внутрь полем json / сериализацией для надежности. json мне нравится больше.
- У корзины неплохо хранить timestamps
- я бы хранил корзины не в той же базе mysql. Либо кэш, либо другая БД (например mongoDb), но я не уверен, что этот совет актуален "для начинающего".
- есть теория, что корзина - это заказ в состоянии "не оформлен". Если следовать ей, то на нее следует посмотреть с точки зрения соответствующей архитектуры. Идеи выше это не учитывают.

Answer 2

[Александр Аксентьев]

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

Вполне достаточно сессии или в крайнем случае кук, особенно для какой-то примитивной реализации без "полноценного" магазина.

Comments

[JhaoDa]

Тонкий момент. Для заказа еды, например, такой вариант подойдёт, но для чего-то «долгоиграющего» уже нет.

[Alex Wells]

Лично я, как юзер, не вижу профита от сохранения товаров в корзину, вообще нигде. Ни при заказе еды, ни в гигантских интернет-магазинах. А вот флуд "вы что-то выбрали" на эмейл, а потом еще и контекстная реклама везде подряд - жутко бесит.

Я максималист, но имхо - это абсолютно ненужная хрень, так что соглашусь с Александром.

[Роман]

Alex Wells, тут другое - по этим данным будет потом и учет вестись и сопровождение. "Корзиной" это я так условно обозвал ))

[JhaoDa]

procode, не надо «условно обзывать», надо нормально объяснять, если хочешь получить нормальный ответ.

[Александр Аксентьев]

procode, ну вот условный ответ и получили.

Если у вас это фактически оформленный заказ, а не корзина, то и ответ будет совсем другим.

[Роман]

Александр Аксентьев, нене, оформление и оплата - это потом. На данном этапе надо просто привязать товар к зарегистрированному юзеру.

Answer 3

[gomer1726]

Предлагаю другой вариант, вот у Вас есть таблица korzina и есть ячейка products_id так вот Вы замучаетесь с этим, проще можно было сериализировать корзину при заказе чтобы потом можно было удобно работать. Да может быть не совсем понятно, но поверьте это того стоит если что пишите объясню или даже покажу исходники

Comments

[Роман]

Спасибо, но мне придется потом работать с этими связями и пр. Сериализация здесь не нужна.

[gomer1726]

procode, наоборот это упрощает дальнейшую работу, просто где надо делаете unserialize и пользуетесь дальше

[JhaoDa]

gomer1726, в курсе, что такое связи?

[gomer1726]

JhaoDa, смотри давай упростим так будет легче понять.
Скажем у тебя есть брат и сестра (Антон и Настя) есть мама есть папа.
Это твои связи. Скажем ты Борис

//это ты сам, в коде мы находим тебя по имени а также ты теперь в объекте $user
$user = User::where('name', 'Борис')->first();

//дальше давай скажем нам необходимо найти твоих близких, мы можем сделать  это так
$user->siblings //брат и сестра
$user->father //папа
$user->mother //мама

В коде мы допускаем что у тебя есть таблица модель и определение связей в модели
Здесь мы конечно упростили но тебе необходимо понять суть
Связи лаварель это мощь, это упрощает работу разработчикам

Еще один пример

//Выбираем категорию с id = 1 (скажем это электроника)
$category = Category::find(1);

//А дальше нам нужно вытащить все товары находящееся в этой категории
//Мы могли бы сделать вот так
$products = Product::where('category', 1)->all();
//Но гораздо легче будет со связями, вот как это будет. Переменную $category мы уже определяли сверху
$products = $category->products

//А в модели Category

public function products()
{
  //так мы создаем связь между товаром и категорией 
  return $this->hasMany('App\Product');
}

Видишь насколько все упростилось

[JhaoDa]

gomer1726, к чему это всё? Доказательство, что вы в курсе, что такое связи и как они хороши? Окей. Тогда почему в ответе хвалите сериализацию?

[Роман]

gomer1726, думаю что под капотом ларавелевского хэзмэни тот же старый добрый WHERE и есть))) это ведь просто обертка для него.

[gomer1726]

JhaoDa, хах, я кажется неправильно истолковал ваш комментарий)) думал что хотите узнать про связи

[gomer1726]

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