Два стола или один стол?

Question

быстрый вопрос относительно дизайна стола ..

Допустим, я проектирую базу данных заявок на кредит. Как сейчас, у меня будет 2 таблицы.

Заявитель (ApplicantID, FirstName, LastName, SSN, Email ...) и

Со-заявитель (CoApplicantID, FirstName, LastName, SSN, Email .., ApplicantID)

Стоит ли рассматривать одну таблицу, потому что все поля одинаковы? ??

Person (PersonID, FirstName, LastName, SSN, Email ..., ParentID (определяет, является ли он со-заявителем))

Каковы плюсы и минусы этих двух подходов?

Answer 1

Я предлагаю следующую модель данных:

PERSON стол

• PERSON_ID, шт

LOAN_APPLICATIONS таблица

• APPLICATION_ID, шт

APPLICANT_TYPE_CODE стол

• APPLICANT_TYPE_CODE, шт
• APPLICANT_TYPE_CODE_DESCRIPTION

LOAN_APPLICANTS стол

• APPLICATION_ID, рк, фк
• PERSON_ID, рк, фк
• APPLICANT_TYPE_CODE, фк

Person (PersonID, FirstName, LastName, SSN, Email ..., ParentID (определяет, является ли он со-заявителем))

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

Это преимущество того, как и почему все нормализуется. Основываясь на бизнес-правилах и реальной реальности использования, таблицы настраиваются таким образом, чтобы предотвратить сохранение избыточных данных. Это по следующим причинам:

1. Избыточные данные - пустая трата пространства и ресурсов для поддержки и обслуживания
2. Действие дублирования данных означает, что они также могут различаться тонкими способами - заглавными буквами, пробелами и т. Д., Что может привести к сложностям при выделении реальных данных
3. Данные неправильно хранятся из-за недосмотра при создании модели данных
4. Предвидение и гибкость. В настоящее время нет другого выбора, кроме заявителя или совместного заявителя для значения APPLICANT_TYPE_CODE - его можно сохранить без использования другой таблицы и внешнего ключа. Но эта настройка позволяет поддерживать добавление различных кодов заявителей в будущем по мере необходимости - без ущерба для модели данных.

Нет никакого выигрыша в производительности, когда вы рискуете получить неверные данные. То, что вы сделаете, будет съедено взломами, которые вы должны выполнить, чтобы заставить вещи работать.

Answer 2

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

Answer 3

Оба ваших варианта имеют один недостаток: любой человек может быть заявителем и соискателем дважды и более. Поэтому вам следует использовать таблицу Person (PersonID, FirstName, LastName, SSN, Email ...) и таблицу Co-Applicants (PersonID в качестве заявителя, PersonID в качестве соисполнителя)

Answer 4

Преимущества : - Упрощает поиск: если у вас есть только номер телефона или имя, вы все равно можете искать в одной таблице и найти соответствующего человека, независимо от того, является ли он / она со-заявителем или основным-заявителем. В противном случае вам нужно будет использовать конструкцию UNION. (Тем не менее, когда вы знаете, что вы ищете заявителя определенного типа, вы добавляете фильтр по типу, и вы получаете только таких заявителей. - Как правило, проще в обслуживании. Скажем, завтра вам нужно добавить идентификатор твитера заявителя ;-), нужно изменить только одно место. - Также позволяет вводить лиц, скажем, типа «открытый / неопределенный», и назначать их в качестве заявителя или иным образом на более поздний срок. - Позволяет вводить новые типы заявителей (скажем, ко-латеральный поручитель ... что угодно) ...

Недостатки :

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

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

Answer 5

Возможно, вы захотите прочитать о нормализации базы данных .

Я думаю, у вас должно быть две таблицы, но не две. Иметь таблицу «ссуды», в которой есть внешние ключи к таблице кандидатов, или просто иметь записи в кандидатах, ссылающиеся на ту же таблицу.

Answer 6

Я знаю - я опоздал на это ... Заявка на кредит - ваша основная сущность. У вас будет один или несколько претендентов на кредит. Отбросьте идею о личности - вы создаете то, что вы не можете контролировать. Я был там, сделал это и получил футболку.

Answer 7

Держите два стола> 1ST код типа пользователя В этой таблице вы можете сохранить тип пользователя, т.е. 2-я таблица User -> здесь вы можете сохранить все поля с похожими столбцами с кодом типа пользователя в качестве ключа foregin Этим вы можете легко расстроить двух пользователей.

Answer 8

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

Answer 9

Как насчет того, чтобы у каждого заявителя мог быть совместный соискатель - достаточно всего одной таблицы. Таким образом, у вас будет Applicants, который имеет необязательное поле внешнего ключа 'coapplicant' (или подобное).