База данных SQL дизайн

Question

Я создаю приложение React, и теперь мне нужно хранить IBAN number, bank_name, bank_location etc... для каждого пользователя, и у каждого пользователя может быть только 1 банк.

В настоящее время у меня есть одна таблица, описывающая пользователя,

User(uid, name, lastname, bio, url_img, ..)

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

Идея 1:

User (  uid
      , name
      , lastname
      , bio
      , url_img
      , IBAN_number
      , bank_name
      , bank_location
      )

Идея 2:

User (uid, name, lastname, bio, url_img)

Bank_user_info(
       id
     , uid_user
     , IBAN_number
     , bank_name
     , bank_location
     )

- это идея 2 - хорошая идея, даже если у пользователя будет максимум только одна строка bank_user_info ???

Answer 1

Первый случай приводит к логическим ошибкам, по существу, user не может существовать без bank. Учитывая, что в одном банке могут быть клиенты, вы, вероятно, будете постоянно повторять банковскую информацию, что в конечном итоге приведет к противоречивости информации. Избыточность приводит к противоречию, рано или поздно.

Во втором случае user является независимым, но (логически) bank не существует без user и такой же проблемы избыточной банковской информации, как в первый случай.

Итак, я бы порекомендовал

-- only attributes relevant to a user
--
user {USER_ID, ...}
  PK {USER_ID}

-- only attributes relevant to a bank
--
bank {BANK_ID, ...}
  PK {BANK_ID}


-- User banking detail (only one bank per user)
--
user_bank {USER_ID, BANK_ID, ACCOUNT_NO, ... }
       PK {USER_ID}
       AK {BANK_ID, ACCOUNT_NO}

FK1 {USER_ID} REFERENCES user {USER_ID}
FK2 {BANK_ID} REFERENCES bank {BANK_ID}

И если пользователь может сделать банк с более чем одним банком:

user_bank {USER_ID, BANK_ID, ACCOUNT_NO, ... }
       PK {USER_ID, BANK_ID}
       AK {BANK_ID, ACCOUNT_NO}

FK1 {USER_ID} REFERENCES user {USER_ID}
FK2 {BANK_ID} REFERENCES bank {BANK_ID}

Примечания:

All attributes (columns) NOT NULL

PK = Primary Key
AK = Alternate Key (Unique)
FK = Foreign Key

Answer 2

Этот ответ объясняет, когда использовать новую таблицу или новый столбец. В вашем случае номер IBAN может быть атрибутом таблицы «Пользователь», однако другие столбцы должны быть частью сущности Банка. Это предотвращает копирование банковской информации (имя, местонахождение) для каждого пользователя. Таким образом, таблицы могут быть такими:

Пользователь (uid, имя, фамилия, биография, url_img, IBAN, bank_id)
Банк (id, bank_name, bank_location)

Answer 3

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

Пересмотрите поля, которые вы предложили для своих таблиц. Таблица пользователей должна содержать уникальную информацию о каждом пользователе, а также идентификатор для идентификации его банка. Таблица информации о банке будет содержать тот же идентификатор, и все остальное, уникальное для каждого банка.

Теперь, когда дисковое пространство дешевле, вы можете рассмотреть возможность размещения всего в одной таблице, если это не слишком громоздко. Но ... предположим, у банка есть 1 000 000 клиентов, а затем он меняет свое имя. Вы бы предпочли обновить 1 000 000 строк в одной гигантской таблице или 1 строку в информационной таблице банка?