Должен ли я нормализовать эту таблицу MySQL

Question

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

Table: member_profile
`UserID`
`PlanID`
`Company`
`FirstName`
`LastName`
`DOB`
`Phone`
`AddressID`
`website`
`AllowNonUserComments`
`AllowNonUserBlogComments`
`RequireCaptchaForNonUserComments`
`DisplayMyLocation`

последние четыре AllowNonUserComments AllowNonUserBlogComments RequireCaptchaForNonUserComments DisplayMyLocation

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

В основном я не уверен, стоит ли мне перемещать эти поля в

новая таблица: member_profile_settings

`UserID`
`AllowNonUserComments`
`AllowNonUserBlogComments`
`RequireCaptchaForNonUserComments`
`DisplayMyLocation`

или, если я просто оставлю это, будет частью таблицы member_profile , так как у каждого участника будут свои настройки.

Цель - примерно 100000 участников в долгосрочной перспективе и от 10 до 20 тысяч в краткосрочной перспективе. Моя главная проблема - производительность базы данных.

И хотя у меня вопрос № 2) имеет ли смысл перемещать контактную информацию участника, такую ​​как адрес, улица, город, штат, почтовый индекс, телефон и т. Д. в таблицу member_profile вместо таблицы адресов и AddressID , как у меня сейчас.

Спасибо

Answer 1

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

Что касается # 2, если вы хотите обдумать возможность того, что участник имеет несколько адресов или телефонных номеров, вам определенно следует поместить их в разные таблицы, разрешив отношения многие-к-одному. Это также может иметь смысл, если вы ожидаете, что несколько пользователей будут использовать один и тот же адрес; таким образом, вы не будете дублировать информацию, поскольку вам придется хранить одну и ту же адресную информацию для нескольких пользователей, вы просто будете ссылаться на таблицу addresses, в которой соответствующая информация будет содержаться один раз на адрес.

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

Answer 2

Я бы сказал «нет» и «да, но» как ответы на 1) и 2). Для # 1 вашими запросами будет намного легче управлять, если вы создадите столбцы для каждого предпочтения. Лучшие системы, с которыми я работал, были сделаны именно так. Перемещение предпочтений в отдельную таблицу с тройками «пользователь, предпочтение, значение» приводит к сложным запросам, которые объединяют несколько таблиц просто для проверки настройки.

Для # 2: нет никакой причины помещать адрес в другую таблицу, потому что один столбец «AddressID» означает, что в любом случае есть только один адрес на члена, и опять же, это только усложнит запросы. Если вы переверните его в обратном направлении и у вас будет таблица адресов, в которую встроены идентификаторы пользователей, это может иметь смысл; Таким образом, делать телефонные номера имеет еще больше смысла, поскольку люди часто имеют несколько телефонных номеров.

Answer 3

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

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

Например, если поля профиля отображаются только на странице профиля, а поля настроек работают на всем сайте, нет необходимости постоянно искать поля профиля.