Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

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

Остальное, скорее, всё верно.

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

Roman Kitaev, то, что в несколько потоков не записать - это плохо, с этим я не смогу смириться)
Хорошо, спасибо.

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

Roman Kitaev, моё приложение находится на одной машине… или я чего-то не знаю?)

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

И не самая лучшая идея хранить часто удаляемые/изменяемые данные в БД - это приведёт к её дефрагментации.

разве изменение неиндексированного столбца (обновление) приводит к дефрагментации?

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

FanatPHP, почему "тоже"?) Типа сначала мне, потом ему?) Я понимаю, что это кэш и хранить сессии в кэш - это даже опасно, не говоря о том, что кэш предназначен для временного хранения данных, которые потерять некритично и ничего не сломается от потери…

Но я читал много где, даже на Хабре, даже в документации PHP, что сессии хранят в Memcached.

Да, повторюсь, я понимаю, что это неправильно: сессия не будет блокироваться, что может привести к проблеме (как например открытие во фреймах несколько страниц, или несколько запросов AJAX, или открытие страницы в двух окнах одновременно); сессию легко потерять, от чего пользователь разлогинется; в кэш хранятся данные, которые потерять не страшно.

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

FanatPHP, ок, буду разбираться)

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

А SQLite почему не подходит под условие масштабирования? Я же в ней только сессии хранить буду. Или дело в блокировке, а не в размере?

Согласен, медленно.

Да, и это плохо))

Поверхностно я его описал

Ещё читал про хранение на стороне клиента в куках, зашифровано, с ключом и т.д. но мне вообще это не подходит. Я не доверяю данным клиента, даже id сессии из Кук проверяю. Да и ограничение данных в куках. В общем, от этого сразу отказался.

Спасибо за ответ)

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

FanatPHP, я лично сравнивал. Брал данные из БД MySQL, сохранял их в файл и в SQlite. Сравнивал… Сто раз получал эти данные из файла - быстро. Столько же раз запрос к SQLite - тоже не долго. Далее, сто раз запрос в БД MySQL - долго, заметно долго. Замеры не проводил, просто проверил. Делал это на OSpanel. От сюда у меня лично такое мнение о мускуле и сложилось.

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

FanatPHP, нет. Только страхи и фантазии.

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

FanatPHP, хорошо. А отдельную базу создавать под сессии - норм? Или в основой (где юзеры, посты, какашки и т.д.) всё это лучше хранить?

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

FanatPHP, ладно… оставим этот холивар. Я написал ранее

Возьмём MySQL метод хранения будет отличным от метода хранения в файлах? Без сериализации? По id сессии каждый раз запрашивать разные данные и обрабатывать их каждый запрос? Или нормальным считается получить данные, обработать их, сериализовать и сохранить в БД? Потом доставать и просто десериализовать без необходимости обработки (как в начале самом)?

что об этом думаешь?

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

FanatPHP, это совсем разное)) что за тупая привычка в этом сообществе вечно сравнивать абсолютно разные понятия?)
Скорость машины зависит от этих новоротов. Чем больше новоротов, тем больше скорость.
Скорость запросов зависит от проверок. Чем больше проверок, теми меньше скорость.

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

FanatPHP, не в этом плане. SQLite не содержит кучу функций, настроек, констант и прочего, что нужно всегда проверять.

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

FanatPHP, не демонизирую я ничего и никого. Ничего я не выдумываю. Я уточняю. А разве нет никаких ответов / запросов?)
Могу. SQLite более примитивна, если сравнивать с мускулом. Поэтому, думаю, запросы типа Select обрабатываются быстрее. Я не прав?

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

DevMan, я ничего не говорил про ЯП, C, компьютеры, его компоненты, зато говорил про базы данных, такие, как MySQL, SQLite и ждал совета о других методах (включая другие БД) и про кэширование, типа Memcached и Redis.

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

На счёт ФС не спорю

Я понимаю, что такое кэш, а что такое хранилище. Я ведь написал, что читал о способах хранения сессии. И то, что это кэш, а не хранилище, я косвенно отметил в его минусах

В Memcached я буду хранить кэш, который не критично потерять, не хотелось бы всё это смешивать в одной области.

Вариант с SQLite мне так понравился… но блин, эти минусы(

… я не говорю, что соединение с мускулом дольше, чем открытие и чтение файла… я именно про запросы и получение результа

- ну запрос потом ответ - это ведь время… большее, чем просто чтение. Нет что ли?)

Возьмём MySQL метод хранения будет отличным от метода хранения в файлах? Без сериализации? По id сессии каждый раз запрашивать разные данные и обрабатывать их каждый запрос? Или нормальным считается получить данные, обработать их, сериализовать и сохранить в БД? Потом доставать и просто десериализовать без необходимости обработки (как в начале самом)?

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

Дмитрий, да, но файлов сессии авторизованных пользователей будет много и их я не удаляю, только по желанию владельца сессии. У владельца редко такое желание появляется)

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

DevMan, ну SQLite - это ведь БД. А Memcached - это кэширование))

Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

Блин, DevMan ты задрал)) нафига тэги SQLite, БД и кэширования удалил? Тут ведь вопрос касаемо всего этого. Мне что, отдельно под каждый тег конкретный вопрос задавать?

Уже какой раз удаляешь важные теги, потом мой вопрос висит неделями без ответа. Лучше бы теги PHP, хранение данных и сессии удалил, а остальное всё оставил. Люди хорошо знающие Memcached, SQLite, MySQL и методы кэширования больше знают, касаемо моего вопроса, чем простые PHPшники {смайл злого фэйспалма}.

Ошибка PHP Parse error, Как исправить?

secret secretom, я продублирую свой ответ из прошлого твоего вопроса

"UPDATE `\"$_SESSION['E-Mail']\"` SET `parameters`="EmailVerified" WHERE `parameters` = "EmailIsNotVerified""

- это пздц, мягко говоря))
У тебя вместо таблицы указан e-mail из сессии. В строку запроса коряво втиснуты строки таблиц, полей и условий. Если впихиваешь массив по индексу, то заключай его в { и }, если там константы, то их нужно конкатенировать точкой. Если просто строки, то они должны быть в строке… А если эти данные подставляет пользователь, то вообще лучше изучить и использовать подготовленные запросы.

Файл храни и запускай в .php. Можно, конечно, одной строкой заставить сервер обрабатывать html, как php, но тебе это не нужно… сейчас, по крайней мере, тебе нужно не это)

И да… всегда отображай ошибки и предупреждения любых уровней.