Дизайн БД :таблица участников отдельная или все в одной таблице?
-
23-08-2019 - |
Вопрос
Я хочу создать таблицу друзей с личной информацией и данными для входа в систему.
Что лучше разделить таблицу участников на 2 таблицы, одна содержит минимальные детали, вторая с другими деталями.
или остаться в одной таблице ?
у меня есть много таблиц, которые содержат внешний ключ участника.
Решение
Это во многом зависит от того, каковы эти "другие" детали.Это распространенный и интересный вопрос, и на первый взгляд "жесткого и быстрого" ответа не существует.Но если мы подумаем об этом более абстрактно, о фактической взаимосвязи между атрибутами ("деталями") любой конкретной вещи, которую вы хотите представить, мы можем найти некоторую ясность.
В своем вопросе вы указываете, что у друзей есть "минимальные" и "другие" детали.Вместо того чтобы классифицировать эти детали как "минимальные" или "другие", давайте классифицируем их по тому, может ли какая-либо индивидуальная ("атомарная") деталь быть полностью определена тем, что делает друга уникальным.
Я предполагаю, что есть какой-то первичный ключ (PK), например, FriendID или адрес электронной почты или что-то в этом роде.Учитывая этот уникальный идентификатор, спросите себя:"Если мне указан только один идентификатор друга (или электронная почта, или что вы используете в качестве PK), в каких деталях этого друга я абсолютно уверен?Например, учитывая FriendID = 2112, я абсолютно точно знаю имя, фамилию и дату рождения этого друга, но я не делайте этого абсолютно точно знайте номер телефона этого друга, потому что их несколько.
Сгруппируйте в одной таблице все детали, которые вам однозначно известны, учитывая PK.Поместите сведения, для которых вам нужно больше данных (например, "домашний" или "рабочий" в случае номеров телефонов), в "дочерние" таблицы, с внешним ключом обратно в "родительскую" таблицу на ПК.(Примечание:Чрезвычайно вероятно, что PK дочерней таблицы будет составным;то есть состоит из PK родительской таблицы и дифференцирующего фактора (например, "дом" или "работа" в этом примере).Составные ключи для многих сторон отношений 1-M очень хороши.)
Любители баз данных называют это разложением, основанным на функциональные зависимости.
Другие советы
Один стол, если не потенциально вам необходимо связать одного участника с несколькими наборами сведений (т. Е. с несколькими адресами электронной почты, группами пользователей, дневным телефоном, ночным телефоном, сотовым телефоном и т.д.).
Никаких вопросов по этому поводу :всегда разделяйте таблицы, когда это имеет логический смысл.
Например :Друг 1 :Том Джонс живет в долине Друг 2 :Эрин Джонс тоже живет их жизнью, так как это его брат
таблицы :
Friends Id Name Address 1 Tom Jones 1 2 Erin Jones 1 Adresses Id Address 1 The valley
В противном случае всегда будут всплывать такие вещи, как :
Friends Id Name Address 1 Tom Jones The Valey 2 Erin Jones The Valley
Что приведет к ошибочным запросам.
Это только одна проблема, их множество.Например, что, если у so есть 2 адреса электронной почты и 3 номера сотовых телефонов?Что делать, если название улицы изменится и на ней будут жить 5 друзей?
Если вы абсолютно уверены, что ваша таблица будет небольшой, и вам не нужно запрашивать ее, то вы могли бы использовать только одну таблицу.Но тогда вы можете просто использовать что-нибудь отличное, например sw, или лист бумаги, если уж на то пошло :-)
Но если вы хотите иметь базу данных, относитесь к ней как к единому целому.
Читайте о Нормализация для всего вопроса в целом.