Підхід HTTP-сесії або бази даних

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

1. Користувач не входить у систему та додає товар у кошик (Анонімний користувач)
2. Користувач входить у систему та додає продукт у кошик.

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

Але все ж нам потрібно створити кошик для цього користувача, щоб створити та зберегти кошик у мене є два варіанти.

1. Коли користувач додає продукт, створіть кошик у базі даних та пов'яжіть цей кошик із цим користувачем, коли він увійшов, перемістіть цей кошик до зареєстрованого користувача.
2. Створіть Корзину, додайте до неї продукт та збережіть його на Сесії, коли користувач увійде в систему, створити Корзину в базі даних та пов’язаного з нею користувача, який увійшов до цього кошика з Користувачем.

Я знаю, що як система «Корзина», керована базами даних, так і основана на сесії може мати як позитивні, так і негативні аспекти, але не впевнений, який із найкращих підходів може враховувати наступні моменти

1. Масштабованість
2. Гнучкість
3. Розширюваність
4. Застосування повинно дбати про швидкість

Шукаєте інформацію про цей аспект, щоб визначити шлях.

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

Зберігайте кошик для покупок у базі даних. Зберігання коштує дешево, і це не повинно бути проблематично продуктивним, щоб запитувати кошик раз у раз.

Обидва способи мають свої переваги та недоліки, але, як я це бачу, зберігання баз даних має дві досить великі переваги.

1. Звітність. Ви не можете повідомляти про занедбані візки, коефіцієнти переходів тощо, якщо дані перебувають у сеансі.
2. Час очікування сеансу. Я був би роздратований, якби я пішов пообідати і повернувся, щоб побачити, що мій кошик випорожнився, оскільки сеанс закінчився. Я думаю, це теж не сподобається роздрібній торгівлі. Ми хочемо підштовхнути користувача до покупки, а не до здачі та відмови.

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

Натомість ми використовуємо HTML5 sessionStorage, щоб зберігати будь-яку інформацію про користувача, яку нам потрібно знову і знову, але не потребуючи щорічного маршрутизатора файлів cookie для збільшення пропускної здатності. Це IE8 +, і всі інші сучасні браузери та мобільні пристрої сумісні з цією технологією. Але ви просто можете зберігати кошик у файлі cookie як резервний запас, оскільки це ми робили раніше. Ось хороший кошик файлів 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.

Що варто подумати:

• Чи потрібно зберігати дані?
• Якщо так, які дані є найважливішими для збереження, щоб краще обслуговувати користувача?
• Масштабованість + зберігання даних - Як ви збережете інформацію про кошик для швидкого пошуку у вашій базі даних для підтримки багатьох користувачів?

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

Вам потрібно тримати перевірку кількості створених під час сеансу візків.