В какой момент нормализация данных становится смехотворной?

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

У меня следующая ситуация:

1. У меня есть таблица Donorи таблица Recipient. Обе таблицы имеют общую информацию, такую ​​как first_name, last_name, email_address, date_of_birthи т. д. Обе таблицы, если вы простите мой объектно-ориентированный язык -, имеют общий абстрактный тип Person. ]. Вполне возможно, что кто-то, кто в какой-то момент Recipient, может позже стать Donorпосредством пожертвования, поэтому важно, чтобы информация не дублировалась в разных таблицах. Должен ли я выбрать шаблон наследования или просто внешний ключ Donorи Recipientдля таблицы Person?

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

   create table person(id int primary key auto increment,..., 
       default_email_address);
   
   create table email_address(id int primary key auto increment, 
       email varchar(255), name varchar(255), is_default bool, person_id int);
   

   . Это немного усложняет ситуацию, как вы можете себе представить. Поле nameтакже включает в себя список значений по умолчанию, а также возможность пользовательского ввода. Я не могу просто сделать его перечисляемым полем, потому что существует вероятность того, что кто-то может добавить много писем, которые могут быть разными... (это тот момент, когда я кричу: "ЭТО ДАЖЕ СТОИТ ЭТО УЖЕ!?!?" и разочароваться в проекте)

Я предполагаю, что на самом деле все сводится к следующему:в какой момент нормализация данных становится смехотворной?Моя цель здесь — создать действительно хорошую как-прямую-совместимую-как-модель данных, которую я не буду корить себя за создание позже.