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


16

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

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

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

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

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

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

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

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


2
Чому? Я запускаю кілька сотень веб-сайтів електронної комерції, і ми зберігаємо все у файлах cookie або localStorage (HTML5). Також сеанси використовують пам'ять. Під час входу в обліковий запис ми використовуємо зашифроване печиво із часовою позначкою. Сеанс нам не потрібен, оскільки, коли сторінка завантажується, ми використовуємо методи HTML5 для зберігання та використання sessionStorage після одного завантаження. Це IE8 + сумісна стандартна веб-техніка.
Джейсон Себрінг

@LuiggiMendoza добре, чому б ні.
Джейсон Себрінг

@ zipstory.com: Я також хотів би ознайомитись із рішенням на базі HTML5, але, оскільки його не підтримують мало браузера, я сумніваюся
Umesh Awasthi

@UmeshAwasthi Я вважаю, що мої клієнти не дбають про дуже маленьку жменьку людей на нижчих браузерах, але очевидно, це поганий підхід, якщо це інший випадок у вашому веб-трафіку. Я знаю, що в багатьох країнах світу використовується XP на IE7, а іноді і в IE6, але деякі продукти моїх клієнтів знаходяться в таких магазинах, як Nordstroms та Macy і т.д., і, здається, це не хвилює.
Джейсон Себрінг

@ zipstory.com: Я працюю з додатком для електронної комерції, де клієнт хоче навіть підтримку IE6, тепер, що ти скажеш, як це :)
Umesh Awasthi

Відповіді:


9

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

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


що робити, коли мені потрібно показати сторінку деталей кошика? ми повинні зберігати / отримувати дані з сеансу чи звертатися за зверненням до бази даних?
Умеш Авасті

Якщо ви зберігаєте реквізити кошика в базі даних, то так, вам потрібно буде натиснути на базу даних.
Якоб Ґаде

7

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

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

6

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

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

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

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


4

Ви припускаєте, що зберігання сеансів та зберігання бази даних є виключними. Вони ні. Але для початку почнемо з того, що вони є.

Перевага для зберігання сеансу є триразовим:

  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 сумісність браузера може бути ретельною увагою.

Я окреслив факти для вас. Сподіваємось, це допоможе вам прийняти правильне рішення для вашої ситуації.


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

@HLGEM Відмінна ідея - я ніколи про це не думав!
Брендон

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

3

Розглянемо два згадані вами випадки використання

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

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

Користувач входить у систему та додає продукт у кошик.

У цьому випадку ви можете поводитися з ним так само, як вище (старовинні веб-сайти електронної комерції), а також додати цю інформацію до бази даних та пов’язати її з користувачем. В основному це використовується для надання відомостей (збережених від сеансу до сеансу) такої інформації, як "Історія перегляду продуктів", "Рекомендації" тощо, тобто аналогічно Amazon.com.

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

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

3
Це також допомагає компанії проаналізувати продажі. Як часто товар кладуть у кошик, але не купують. Якщо відсоток високий, вони можуть захотіти подивитися, як представлений товар або ціну, щоб побачити, чи зміни можуть допомогти імпортувати курс покупки. Збереження може також дозволити користувачеві швидко бачити ці предмети, якщо він не замовляв їх у той день, коли він його шукав, а не шукати їх знову. Тож, можливо, ви поклали їх у свій кошик, але хотіли зачекати до завтра (день оплати), щоб фактично їх придбати. Таким чином, збереження даних може призвести до того, що ваші реальні клієнти купують більше речей.
HLGEM

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

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

@HLGEM: Дуже хороший момент! Я відповів на це запитання лише на основі необхідності підтримувати функціональність автомобіля для гостя, а не учасника сайту. З точки зору бізнесу, повинна існувати окрема система статистики, яка залежить від якоїсь системи баз даних, яка відстежує продукти (продукти) з точки зору географії, кількості користувачів, супутніх товарів, купують проти
відмов

0

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.