HTTP-сеанс или база данных

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

1. Пользователь не залогинен и не добавляет продукт в корзину (Анонимный пользователь)
2. Пользователь залогинен и добавляет товар в корзину.

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

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

1. Когда пользователь добавляет товар, создает корзину в базе данных и связывает эту корзину с этим пользователем, в тот момент, когда он вошел в систему, переместите эту корзину вошедшему в систему пользователю.
2. Создайте корзину, добавьте продукт в нее и сохраните ее в сеансе, когда пользователь вошел в систему создания корзины в базе данных и связал зарегистрированного пользователя с этой корзиной с пользователем.

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

1. Масштабируемость
2. гибкость
3. растяжимость
4. Приложение должно заботиться о скорости

Ищите вход по этому аспекту, чтобы решить путь.

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

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

Оба метода имеют свои преимущества и недостатки, но, как я понимаю, хранение базы данных имеет два довольно больших преимущества.

1. Составление отчетов. Вы не можете сообщить об оставленных корзинах, коэффициентах конверсии и т. Д., Если данные находятся в сеансе.
2. Тайм-ауты сессии. Я был бы раздражен, если бы я пошел пообедать и вернулся, чтобы найти мою тележку опустошенной, потому что сеанс истек. Я бы подумал, что розничному торговцу это тоже не понравится. Мы хотим подтолкнуть пользователя к покупке, а не к сдаче и уходу.

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

Вместо этого мы используем HTML5 sessionStorage для сохранения любой пользовательской информации, которую нам нужно извлекать снова и снова, но без необходимости каждый раз использовать cookie-файл для увеличения пропускной способности. Это IE8 +, и все другие современные браузеры и мобильные устройства совместимы с этой технологией. НО вы можете просто сохранить корзину в cookie-файле в качестве запасного варианта, поскольку это то, что мы делали ранее. Вот хорошая корзина печенья: http://simplecartjs.org/

Когда пользователи входят в систему или входят в систему, мы используем зашифрованный файл cookie с отметкой времени.

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

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

Преимущество хранения сеансов в три раза:

1. Нет необходимости явно вставлять данные в базу данных. Вы просто устанавливаете переменную сеанса, и все готово. Простой и с низким уровнем риска функционально.
2. Нет необходимости управлять жизненным циклом посещения пользователя и корзины покупок, поскольку контейнеры / фреймворки делают это за вас
3. Обычно автоматическая очистка старых сессий выполняется за вас.

Недостатки хранения сессии:

1. Привязанность сеанса, если вы не исследуете репликацию
2. Нет аварийного переключения, если только вы не исследуете репликацию или ручное сохранение состояния сеанса на диск, что может стать сложным.
3. Все сеансы должны храниться в памяти. Это усиливается, если вы используете репликацию.

Преимущества хранения базы данных:

1. Не нужно беспокоиться о схожести сеанса или репликации состояния. Вы можете округлить все запросы.
2. Меньше накладных расходов памяти в приложении.
3. Если заказ выполнен, все в конечном итоге попадает в базу данных, так что это может упростить завершение, поскольку данные уже присутствуют.

Недостатки хранения базы данных:

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

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

Преимущества сеанса, поддерживаемого базой данных:

1. Нет необходимости в привязке к серверу.
2. Легко в памяти сервера приложений
3. Данные незанятого / заброшенного сеанса очищены для вас.
4. Жизненный цикл первого посещения пользователя, повторного посещения, завершения сеанса - все для вас.
5. Легко кодировать

Недостатки сеанса, поддерживаемого базой данных:

1. Конфигурация - вам нужно исследовать свой контейнер, будь то PHP, Java EE (Tomcat, Jetty, JBoss и т. Д.), Node.js + express.js или еще что-то, поддерживающее это, и предоставить правильную конфигурацию.
2. Вам может потребоваться загрузить это тестирование, так как вы добавляете 2 операции с базой данных на запрос.

Есть третья возможность, о которой кто-то упоминал ранее. Вы можете вообще отказаться от использования сессий и использовать хранилище на стороне клиента, либо встраивая все в cookie, либо в локальное html-хранилище.

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

Я изложил факты для вас. Надеюсь, это поможет вам принять правильное решение для вашей ситуации.

Давайте рассмотрим два варианта использования, которые вы упомянули

Пользователь не залогинен и не добавляет продукт в корзину (Анонимный пользователь)

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

Пользователь залогинен и добавляет товар в корзину.

В этом случае вы можете обрабатывать его так же, как описано выше (сайты электронной коммерции старой школы), а также добавлять эту информацию в базу данных и связывать ее с пользователем. Это в основном используется для предоставления информации о состоянии (состояние сохраняется от сеанса к сеансу), такой как «История просмотра продукта», «Рекомендации» и т. Д., Например, аналогично Amazon.com.

Что нужно подумать:

• Нужно ли сохранять данные?
• Если да, какие данные наиболее важно сохранить для лучшего обслуживания пользователя?
• Масштабируемость + хранение данных - Как вы будете сохранять информацию о корзине для быстрого поиска в вашей базе данных, чтобы поддержать многих пользователей?

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

Вам необходимо следить за количеством создаваемых тележек в сеансе.