Дизайн БД :таблица участников отдельная или все в одной таблице?

Question

Я хочу создать таблицу друзей с личной информацией и данными для входа в систему.

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

или остаться в одной таблице ?

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

Answer 1

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

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

Я предполагаю, что есть какой-то первичный ключ (PK), например, FriendID или адрес электронной почты или что-то в этом роде.Учитывая этот уникальный идентификатор, спросите себя:"Если мне указан только один идентификатор друга (или электронная почта, или что вы используете в качестве PK), в каких деталях этого друга я абсолютно уверен?Например, учитывая FriendID = 2112, я абсолютно точно знаю имя, фамилию и дату рождения этого друга, но я не делайте этого абсолютно точно знайте номер телефона этого друга, потому что их несколько.

Сгруппируйте в одной таблице все детали, которые вам однозначно известны, учитывая PK.Поместите сведения, для которых вам нужно больше данных (например, "домашний" или "рабочий" в случае номеров телефонов), в "дочерние" таблицы, с внешним ключом обратно в "родительскую" таблицу на ПК.(Примечание:Чрезвычайно вероятно, что PK дочерней таблицы будет составным;то есть состоит из PK родительской таблицы и дифференцирующего фактора (например, "дом" или "работа" в этом примере).Составные ключи для многих сторон отношений 1-M очень хороши.)

Любители баз данных называют это разложением, основанным на функциональные зависимости.

Answer 2

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

Answer 3

Никаких вопросов по этому поводу :всегда разделяйте таблицы, когда это имеет логический смысл.

Например :Друг 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, или лист бумаги, если уж на то пошло :-)

Но если вы хотите иметь базу данных, относитесь к ней как к единому целому.

Читайте о Нормализация для всего вопроса в целом.