В кадровсой программе возможны NULL
Дата смерти
Дата Увольнения
Дата выхода на пенсию
Имеющиеся правительственные награды
Телефон
И дофига других.

Возможны, но необязательны.
Например, если норамализовать далее (и зачастую это более правильно)
до отдельных таблиц:
Факты смерти
Факты Увольнения
Факты выхода на пенсию
...

угу.. и при добавлении, например "Факта удаления аппендицита" добавлять
табличку... процедуру для обработки... интерфейса... вместо того чтобы
добавить в табличку, скажем "разные факты" новой записи "Факт удаления
аппендицита"....

Это уже дело CRUD-слоя раскладывать записи по табличкам, зачастую эту кажущуюся в данном случае сложно процедуру можно сгенерить автоматом на основнии модели данных.
Интерфейс ничем не пострадает, надо просто вспомнить паттерн MVC
Потом в данном случае повышается процент повторного использования кода, не во всех же разработках требуется хранить факт удаления аппендицита, но вот ФИО - везде, таким образом вы выделяете некое общее ядро для различных модулей, которое наращивается в соответствии с требованиями к системе.

и кстати, а если мне понадобится например, жизнеописание чела?
я что, должен буду писать
select * from ФактРождения union all
select * from ФактОбучения union all
.......
select * from ФактСмерти
order by date
некошерно это как-то....

не union all, а обычный join если связь 1-к-1.
Для сложных иерархических объектов - их можно вообще в xml возвращать, далее десериализовывать в бизнес-объект/компонент.

locky
у-ху... т.е. процы генерятся... сами по себе... не проще ли заполнить
справочник типов фактов?

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

кто такой MVC - не знаю, подозреваю что Microsoft Visual C
Если да, то что, при добавлении нового факта Вы предлагаете
перекомпилить клиента? Или я неправильно понимаю?

MVC - это Model View Controller - другими словами отделение данных и управления ими от презентационного уровня (интерфейса)
По поводу же перекомпиляции... думаю вам известно что написание полностью тонко настраиваемого приложения на все случаи - это миф.

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

Если факты храняться в одной таблице - у вас будут NULL-ы - вообщем то это тема данного топика...
другие доводы в пользу отделения я описал выше.

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

структура хранения истории бизнес-объекта определяется на этапе проектирования. т.е. например вы определяете что добавлять в историю при изменении объекта: весь список 1-к-n либо хранить историю для каждой изменяемой записи списка. В общем случае для истории делается поностью дублирующая структура с дополнительными полями типа дата создания/изменения.
И потом, как в вы предлагаете хранить обучение/увольнение/женитьба/развод в одной таблице? нет, ну можно конечно в xml например, но... очень сомнительное решение.
И по поводу join-а при 1-к-n , в mssql ,например, вы можете сделать for xml запрос который и вернет вам всю иерархию бизнес объекта в виде xml.

дорогой locky, видимо мы с вами разговариваем на разных языках
по-этому попытаюсь подвести некое резюме.

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