У меня есть база данных, в которой хранится много информации о продуктах (год, название, дата выпуска, объем и т. Д.). В настоящее время я загружаю все продукты один раз и сохраняю их в переменной сеанса - сейчас их всего 8, но список будет расти со временем. Причина, по которой я сделал это, заключалась в том, чтобы (возможно, по глупости) сохранять чтения с жесткого диска каждый раз, когда открывался доступ к странице продуктов. Я стреляю себе в ногу, сохраняя эту информацию в сеансе?
Да, наверное, ты прострелил себе ногу. Если в каждом пользовательском сеансе сохраняется вся информация о продукте, у вас может закончиться память, если у вас много пользователей и много продуктов.
Я бы предложил использовать что-то вроде memcached для кеширования запросов к таблице продуктов, чтобы вы не слишком сильно ударяли по диску, но и не исчерпывали память.
Но это действительно зависит от того, какой масштаб вы ожидаете - если у вас будет только 50 КБ данных о продукте и 500 одновременных пользовательских сеансов, тогда вы будете есть только 25 МБ, и, вероятно, вам это сойдет с рук. . Если вы ожидаете 50 МБ данных о продукте и 50 000 пользовательских сеансов, то вы будете использовать 2,5 ТБ оперативной памяти, которой у вас, вероятно, не будет.
Если у вас всего 8 продуктов, вам не нужна база данных :-)
Если вы хотите использовать базу данных (что, вероятно, является хорошей идеей, если сайт будет расти), вы также можете использовать базу данных и просто указать на нее массив ключей продукта сеанса. Наличие дублирующейся информации во время сеанса - это больно и ненужно - почему она есть в двух местах?
Если к базе данных часто обращаются, вся информация таблицы продуктов, скорее всего, в любом случае находится в памяти, поэтому вам не нужно добавлять какие-либо дополнительные сложности. Для большинства сайтов memcached - это просто способ ускорить действительно плохо спроектированные запросы к базе данных или ORM.