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

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

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

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

Спасибо!

Ответы [ 10 ]

3 голосов
/ 16 февраля 2010

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

3 голосов
/ 16 февраля 2010

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

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

0 голосов
/ 16 февраля 2010

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

0 голосов
/ 16 февраля 2010

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

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

0 голосов
/ 16 февраля 2010

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

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

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 является пользователем.

0 голосов
/ 16 февраля 2010

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

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

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

0 голосов
/ 16 февраля 2010

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

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

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

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

0 голосов
/ 16 февраля 2010

MongoDB (и его двоюродные братья по NoSQL) отлично подходят для подобных вещей.

0 голосов
/ 16 февраля 2010

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

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

0 голосов
/ 16 февраля 2010

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

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

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

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

id  | user_id | variable_name | variable_value

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...