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

Question

Я прошу прощения, если это просто еще один способ задать вопрос о месте хранения в таблице MySQL, например: NULL в MySQL (производительность и хранение)

но мой вопрос действительно относится к наилучшей практике.

Проблема

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

Рекомендуется ли добавлять новые поля в мою существующую таблицу, устанавливать и разрешать всем начальным значениям значение NULL, а затем обновлять существующие записи новыми данными

OR

создать новую таблицу (таблицы) и установить связь с первичной таблицей на основе наличия первичного ключа?

Answer 1

Не беспокойтесь о добавлении столбцов в таблицу, будь то сегодня или спустя 12 месяцев.Вместо этого просто подумайте об отношениях.Между человеком и его полом и днем ​​рождения существует соотношение 1: 1, поэтому имеет смысл сохранить эти атрибуты в существующей таблице, а не создавать новую.

Answer 2

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

Answer 3

Я не эксперт здесь, так что это может быть не очень хороший ответ. Просто хотел поставить одну точку в перспективе:

Возможен один недостаток добавления столбцов в существующую таблицу: если вы используете ORM (например, hibernate), он будет извлекать все столбцы при выполнении запроса выбора. Таким образом, если количество строк становится больше, нужно получить больше данных, поэтому запрос может стать медленнее. Если столбец используется не часто, возможно, имеет смысл создать отдельную таблицу?

Answer 4

Я предлагаю добавить новые таблицы.

В реляционной модели отсутствует ноль. Используя допущение о замкнутом мире, смоделируйте недостающую информацию путем ее отсутствия в отношении (и, следовательно, в базе данных). Трехзначная логика SQL неинтуитивна и приводит к частым ошибкам (множество доказательств этого в Stackoverflow!). Поэтому не пытайтесь вводить значения Nullable в ваши таблицы SQL. Нормализация до наивысшей нормальной формы (6NF) приведет к тому, что ваши новые атрибуты будут находиться в отдельных таблицах.

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

Незначительный балл: пол = женский, мужской и т. Д., Пол = женский, мужской и т. Д.

Answer 5

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

Здесь играет роль не просто пространство, а моделирование ваших данных для конкретного продукта.моделирование поможет вам понять и продолжить разработку приложения по мере его роста и изменения.

Надеюсь, что это помогло.