Довге зберігання кошика в інтернет-магазині

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

Розглянемо кожен з варіантів :

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

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

2. У Cookie . Цей спосіб зберігання також можливий у використанні довгострокового зберігання кошика. Його плюсом є те, що кукі можна використовувати як для зареєстрованого користувача, так і для не залогіненого.

Мінус такого способу в пам'яті , яка виділена для одного осередку з кук , а саме 4кб . Але ця цифра може відрізнятись залежно від браузера – це ще один мінус.

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

Можна якось будувати "велосипед" по розподілу кук. Наприклад одна кука - одна позиція товару, а потім якось їх відловлювати і формувати цілий кошик, але це не варто .

3. У сесії . На мою думку, цей спосіб не практичний. За замовчуванням сервер тримає сесію клієнта 1440 секунд , якщо за цей час клієнт закрив браузер і не встиг оформити замовлення, то весь набраний кошик буде втрачено.

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

Оптимальне довгострокове зберігання кошика :

На мій досвід, найоптимальнішим способом зберігання кошика стане використання комбінації " база+cookie ". Така зв'язка працюватиме з усіма плюсами кук та бази.

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

2. В основі створюємо таблицю з полями: ідентифікатора (описаний вище), id користувача (якщо був авторизований), часу останнього оновлення та самих даних про кошик.

3. Пишемо мінімальний контролер, що працює з цим все.

Я покажу наочно, як реалізовувати це на вашому сайті вирішите самі.

Допустимо така структура таблиці :

CREATE TABLE `cart_table` (
`cart_key` varchar(50) CHARACTER SET utf8 NOT NULL,
`user_id` int(11) NOT NULL,
`last_update` int(11) NOT NULL,
`cart_data` text CHARACTER SET utf8 NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Схематичний код роботи :

<?php
/**
* Функція витягує з таблиці кошика дані
*/
function getCartData () {
    /*Запускаємо initCartCookie()*/
    $key = initCartCookie();

    /*За ключом шукаємо запис cart_key*/
    /*Далі потрібна інформація з обробки*/
}

/**
* Функція записує дані в кошик
*/
function setCartData () {
    /*Запускаємо initCartCookie()*/
    $key = initCartCookie();
    
    /*За ключом шукаємо запис cart_key, якщо ні то створюємо*/
    /*Далі потрібна інфа з обробки*/
}

/**
* Якщо ідентифікатор вже є, повертаємо його, якщо ні, створюємо та повертаємо
*/
function initCartCookie() {
    if (isset($_COOKIE['cart_key']) && trim($_COOKIE['cart_key'])) {
        return strip_tags(trim($_COOKIE['cart_key']));
    } else {
        $key = base64_encode(time() . '-' . rand(10,99). '-' . rand(10,99));
        setcookie("cart_key", $key, (time()+(86400 * 30)));
        return $key;
    }
}

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