Веб-сайт:Как лучше всего хранить большое количество пользовательских переменных?

StackOverflow https://stackoverflow.com/questions/2269294

  •  20-09-2019
  •  | 
  •  

Вопрос

В настоящее время я разрабатываю веб-сайт с использованием PHP и MySQL, и по мере работы над сайтом я добавляю все больше и больше столбцов в таблицу пользователей для хранения различных переменных.

Это заставило меня задуматься: есть ли лучший способ сохранить эту информацию?Просто чтобы уточнить: информация является глобальной, на нее могут влиять другие пользователи, поэтому файлы cookie не будут работать, а также я потеряю информацию, если они очистят свои файлы cookie.

Вторая часть моего вопроса: если окажется, что хранить его в базе данных - лучший способ, будет ли дешевле иметь большое количество столбцов или, скорее, объединить связанные столбцы в столбцы с разделителями varchar, а затем разбить их? в PHP?

Спасибо!

Это было полезно?

Решение

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

Кроме того, если ваша таблица слишком сильно разрастается, возможно, вам нужно рассмотреть возможность разделения ее на несколько таблиц, объединенных внешними зависимостями?

Другие советы

Я бы создал user_meta таблица с тремя столбцами: user_id, key, value.

Я бы не стал использовать вариант группировки столбцов и их разбивки.Это неопрятная работа и очень неуправляемая.Вместо этого, возможно, попробуйте распределить эти столбцы по нескольким таблицам и использовать функцию транзакций InnoDb.

Если вам по-прежнему не нравится идея частого обновления базы данных, и если этот метод соответствует тому, чего вы пытаетесь достичь, вы можете использовать Функция кэширования APC хранить (кэшировать) информацию «глобально» на сервере.

MongoDB (и его родственники NoSQL) отлично подходят для подобных задач.

База данных — прекрасное место для хранения таких данных, если они представляют собой переменные, а не, скажем, огромные файлы изображений.База данных имеет все оптимизации и спецификации для хранения и извлечения больших объемов данных.Все, что вы настроите на уровне файловой системы, всегда будет превосходить то, что уже есть в базе данных, с точки зрения скорости и функциональности.

было бы дешевле иметь большое количество столбцов или, скорее, объединить связанные столбцы в столбцы с разделителями varchar, а затем разбить их на PHP?

Это не так уж и много производительность чем обслуживание вопрос, ИМХО - управлять сотнями столбцов неинтересно.Хранение таких данных – возможно, как сериализоватьd объекты - в TEXT поле является жизнеспособным вариантом - если оно на 100% уверено, что вам никогда не придется делать какие-либо запросы к этим данным.

Но почему бы не использовать нормализованный user_variables таблица такая:

id  | user_id | variable_name | variable_value

?

Запрос немного сложнее, но обеспечивает очень чистая структура стола со всех сторон.Таким образом вы можете легко добавлять произвольные пользовательские переменные.

Если вы делаете много запросов, таких как SELECT FROM USERS WHERE variable257 = 'green' возможно, вам придется придерживаться определенных столбцов.

База данных определенно является лучшим местом для хранения данных.(Я предполагаю, что в противном случае вы думали о хранении его в плоских файлах). Вы определенно получите лучшую производительность и безопасность от использования БД по сравнению с хранением в файлах.

Что касается хранения ваших данных в нескольких столбцах или их разграничения...Это ваш личный выбор, но вам следует учитывать несколько вещей.

  1. Если вы собираетесь разграничивать элементы, вам нужно подумать о том, чем вы собираетесь их разграничивать (что-то, что вряд ли появится в тексте, который вы разграничиваете).
  2. Я часто обнаруживаю, что полезно попытаться представить себе, сможет ли другой программист вашего уровня понять, что вы сделали, без особой помощи.
  3. Да, как сказал Пекка, если вы хотите выполнять запросы к хранящимся данным, вам следует придерживаться отдельных столбцов.
  4. Вы также можете получить небольшой прирост производительности, если не будете каждый раз извлекать и анализировать ВСЕ ваши данные, если вам просто нужна пара полей информации.

Я бы предложил использовать отдельные столбцы, поскольку это дает вам возможность гораздо большей гибкости в будущем.И нет ничего хуже, чем радикально изменить структуру данных и перенести информацию в дальнейшем!

Я бы рекомендовал настроить memcached-сервер (см. http://memcached.org/).Он доказал свою жизнеспособность со многими большие сайты.PHP имеет два расширения, которые интегрируют клиент в вашу среду выполнения (см. http://php.net/manual/en/book.memcached.php).

Попробуйте, вы не пожалеете.

РЕДАКТИРОВАТЬ
Конечно, это будет вариант только для часто используемых данных, которые в противном случае придется загружать из базы данных снова и снова.Имейте в виду, однако, что вам все равно придется сохранять данные в каком-то постоянном хранилище.

Документно-ориентированная база данных может оказаться тем, что вам нужно.

Если вы хотите придерживаться реляционный базы данных, не прибегайте к наивному подходу и просто создайте таблицу с таким большим количеством полей:

CREATE TABLE SomeEntity (
    ENTITY_ID    CHAR(10)    NOT NULL,
    PROPERTY_1   VARCHAR(50),
    PROPERTY_2   VARCHAR(50),
    PROPERTY_3   VARCHAR(50),
    ...
    PROPERTY_915 VARCHAR(50),
    PRIMARY KEY  (ENTITY_ID)
);

Вместо этого определите таблицу атрибутов:

CREATE TABLE Attribute (
    ATTRIBUTE_ID  CHAR(10) NOT NULL,
    DESCRIPTION   VARCHAR(30),
    /* optionally */
    DEFAULT_VALUE /* whatever type you want */,
    /* end_optionally */
    PRIMARY KEY   (ATTRIBUTE_ID)
);

Затем определите таблицу SomeEntity, которая включает только основные атрибуты (например, обязательные поля в регистрационной форме):

CREATE TABLE SomeEntity (
    ENTITY_ID   CHAR(10) NOT NULL
    ESSENTIAL_1 VARCHAR(30),
    ESSENTIAL_2 VARCHAR(30),
    ESSENTIAL_3 VARCHAR(30),
    PRIMARY KEY (ENTITY_ID)
);

А затем определите таблицу для тех атрибутов, которые вы можете или не хотите хранить.

CREATE TABLE EntityAttribute (
    ATTRIBUTE_ID    CHAR(10) NOT NULL,
    ENTITY_ID       CHAR(10) NOT NULL,
    ATTRIBUTE_VALUE /* the same type as SomeEntity.DEFAULT_VALUE;
                       if you didn't create that field, then any type */,
    PRIMARY KEY     (ATTRIBUTE_ID, ENTITY_ID)
);

Очевидно, в вашем случае SomeEntity является пользователем.

Вместо MySQL вы можете рассмотреть возможность использования тройной магазин, или хранилище ключей-значенийТаким образом, вы получаете все преимущества многопоточности, многопользовательской работы, производительности и кэширования, выясненные, без каких-либо проблем с попытками заранее выяснить, какие значения вы действительно хотите сохранить.

Недостатки:немного сложнее вычислить среднюю зарплату всех жителей Айдахо, у которых тоже есть шляпы.

зависит от того, какую информацию о пользователе вы храните.если это данные, относящиеся к сеансу, используйте сеансы php в координации с обработчиками событий сеанса для хранения данных вашего сеанса в одном поле данных в базе данных.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top