Дизайн БД: таблица элементов отдельно или все в одной таблице?

Question

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

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

или оставаться в одном столе?

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

Например: Друг 1: Том Джонс живет в долине другу 2: Erin Джонс живет их также, так как это его брат

столы:

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 

Это приведет к ошибочным запросам.

Это только одна проблема, их много. Например, если у этого есть 2 адреса электронной почты и 3 номера сотовых телефонов? Что делать, если название улицы меняется и в ней живут 5 друзей?

Если вы уверены, что ваш стол будет небольшим, и вам не нужно его запрашивать, вы можете использовать только одну таблицу. Но вы можете просто использовать некоторые прецеденты, такие как sw too, или листок бумаги в этом отношении :-)

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

Подробнее о Normalization.