Я хочу создать таблицу друзей с личной информацией и войти в систему.
Что лучше разделить таблицу участников на 2 таблицы, одна содержит минимальные детали, а вторая - другие детали.
или оставаться в одной таблице?
У меня много таблиц, содержащих внешний ключ члена.
Это во многом зависит от того, что это за «другие» детали. Это частый и интересный вопрос, на который, на первый взгляд, нет однозначного ответа. Но если мы подумаем о проблеме более абстрактно, о фактических отношениях между атрибутами («деталями») любой конкретной вещи, которую вы хотите представить, мы можем найти некоторую ясность.
В своем вопросе вы указываете, что у друзей есть «минимальные» и «прочие» детали. Вместо того, чтобы классифицировать эти детали как «минимальные» или «прочие», давайте классифицируем их по тому, может ли какая-либо отдельная («атомарная») деталь быть полностью определена тем, что делает друга уникальным.
Я предполагаю, что есть какой-то первичный ключ (PK), например FriendID, адрес электронной почты или что-то в этом роде. Принимая во внимание этот уникальный идентификатор, спросите себя: «Если мне дают ровно один FriendID (или адрес электронной почты, или что-то еще, что вы используете в качестве PK), в каких деталях этого друга я абсолютно уверен? Например, учитывая FriendID = 2112, я абсолютно уверен. знаю имя, фамилию и дату рождения этого друга, но я не абсолютно знаю номер телефона этого друга, потому что их несколько.
Сгруппируйте в одну таблицу все детали, которые вы однозначно знаете по ПК. Поместите детали, для которых вам нужно больше данных (например, «домашний» или «рабочий» в случае телефонных номеров), в «дочерние» таблицы, связанные внешним ключом с «родительской» таблицей на ПК. (Примечание. Весьма вероятно, что PK дочерней таблицы будет составной, то есть составленной из PK родительской таблицы и дифференцирующего фактора (например, «домашний» или «рабочий» в этом примере). Составные ключи для многих сторон отношений 1-М очень хорошие.)
Специалисты по базам данных называют эту декомпозицию на основе функциональных зависимостей.
Одна таблица, если вам потенциально не нужно связать одного участника с несколькими наборами данных (например, несколько адресов электронной почты, группы пользователей, дневной телефон, ночной телефон, мобильный телефон и т. Д.).
В этом нет сомнений: всегда разделяйте таблицы, когда это имеет логический смысл.
Например: Друг 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
Что приведет к ошибочным запросам.
Это всего лишь одна проблема, их много. А что, если у вас 2 адреса электронной почты и 3 номера сотовых телефонов? Что, если название улицы изменится и на нем будут жить 5 друзей?
Если вы уверены, что ваша таблица будет небольшой и вам не нужно ее запрашивать, вы можете использовать только одну таблицу. Но вы можете просто использовать какое-нибудь превосходство, например sw, или лист бумаги, если на то пошло :-)
Но если вы хотите иметь базу данных, относитесь к ней как к единой.
Прочтите о Нормализации всего вопроса.
