Управление базой данных и таблицами - PullRequest
1 голос
/ 08 февраля 2011

Я занимаюсь созданием веб-приложения и надеюсь его расширить. В моем веб-приложении у меня есть таблица для пользователей, включающая привилегии для отслеживания того, является ли пользователь администратором, очень маленькая таблица для раздела динамического содержимого страницы и таблица для отслеживания «событий» на веб-сайте.

Будучи не очень опытным в создании веб-приложений, я не совсем уверен, как профессионалы будут создавать системы баз данных и таблиц для веб-приложений. В моем веб-приложении я планирую добавить дополнительные пользовательские настройки для каждого участника веб-сайта и даже системы обмена сообщениями. В настоящее время я использую PHP с базой данных MySQL, которую запрашиваю для всех моих команд, но я бы хотел изменить все это, если это необходимо. Что было бы лучше для отслеживания контента, такого как сообщения, которые являются межличностными, а также конкретные настройки пользователя для каждого пользователя. Хотел бы я иметь несколько баз данных в любой момент? Я хотел бы иметь несколько таблиц для каждого пользователя, возможно? Любая информация о том, как это делается или должна быть сделана, будет весьма полезна.

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

Ответы [ 3 ]

1 голос
/ 08 февраля 2011

Вот мой, казалось бы, длинный, надеюсь, не слишком запутанный ответ на ваш вопрос. Я думаю, что покрыл большинство, если не все ваши запросы.

Для вашего веб-приложения у вас может быть таблица пользователей с именем «Пользователи», таблица настроек с именем «UserSettings» или что-то такое же описательное, а также сообщения в таблице «PrivateMessages». Тогда могут быть дочерние таблицы, в которых хранятся необходимые дополнительные данные.

Безопасность пользователя может быть сложной задачей при разработке и реализации. Вы хотите сделать это по группам (если вы планируете иметь много пользователей, упрощая управление их разрешениями), или просто назначать их индивидуально из-за небольшой базы пользователей? Для обеспечения безопасности вам понадобятся 4 таблицы:

Users
UserSettings
UserGroups
UserAssignedGroups

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

В своих сообщениях храните их не с именем пользователя, а с идентификатором пользователя. Например, в вашей таблице PrivateMessages вы должны иметь MessageID, SenderUserID, RecipientUserID, Subject, Body и DateSent для хранения самой основной информации. Таким образом, когда пользователь хочет проверить свои полученные сообщения, вы можете запросить таблицу, сказав:

   SELECT * FROM PrivateMessages WHERE RecipientUserID = 123556

Список таблиц для ваших сообщений может быть таким:

PrivateMessages
MessageReplies

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

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

0 голосов
/ 08 февраля 2011

В соответствии с комментариями Кристиана Раду: вам нужно разбить данные на разные таблицы. Таблица Lean для пользователя будет (на самом деле, должна иметь) один уникальный идентификатор для каждого пользователя. Этот (уникальный) ключ должен быть повторен во вторичных таблицах. Затем он будет называться внешним ключом. Очевидно, вам нужен уникальный ключ. Если ваше имя пользователя может быть гарантировано уникальным (то есть вы хотите, чтобы пользователь был идентифицирован по его адресу электронной почты), то вы можете использовать это. Если имена пользователей - это настоящие имена (например, Имя, Фамилия), то у вас нет такой гарантии, и вам нужно сохранить идентификатор пользователя, который станет вашим ключом. Аналогично, таблица, содержащая ваши сообщения, может (но не обязана) иметь поле с уникальными идентификаторами пользователей, указывающими, кто его написал и т. Д.

Возможно, вы захотите немного прочитать о дизайне базы данных и концепции нормализации: (http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html) Нет необходимости увязать в n-й форме нормализации, но это поможет вам на этом этапе, когда вам нужно разобраться дизайн базы данных.

Удачи и доложить; -)

0 голосов
/ 08 февраля 2011

Для работы вашего веб-приложения вам не нужно несколько баз данных. Однако вам нужно несколько таблиц для эффективного хранения ваших данных.

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

Сообщения могут быть хитрее, потому что они на порядок больше - у вас может быть десятки или сотни для каждого пользователя. Вам необходимо спроектировать структуру таблиц на основе логики вашего приложения. Таблица для каждого пользователя явно не является возможным решением, поэтому перейдите к общей таблице сообщений, но реализуйте процедуры, чтобы сохранить ее в управляемом размере. Примером может служить «архивация» сообщений старше X дней, что приведет к их перемещению в другую таблицу (что хорошо работает, если ваши пользователи вряд ли получат доступ к своим старым сообщениям слишком часто). Но, как я уже сказал, это зависит от вашего приложения.

Удачи!

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