Я так и думал, что увижу у Вас этот хорошо известный приём - известный в серьёзных приложениях (просто не встречающийся в "мелкой автоматизации" на Access и проч.): использование одной таблицы для поатрибутного, "измельчённого" хранения объектов. "Виртуальные таблицы" на базе однородной.
В случае, когда количество видов информационных объектов заранее, на этапе создания информационной системы, неизвестно, когда могут динамически добавляться новые виды объектов и атрибуты, либо когда объекты имеют сильно нерегулярный набор полей (меняющийся от экземпляра к экземпляру, так что либо понабодится очень много таблиц, либо таблицы будут сильно разрежёнными) - используется как раз такой приём.
Конечно, можно любую БД привести в такой вид (как любое высокоуровневое представление данных, в конечном счёте, хранится в памяти в каком-то технически однородном виде). В некоторых реализациях СУБД хранение происходит именно подобным образом.
Но без нужды злоупотреблять такой структурой не следует:
1) Зверски теряется эффективность - для сбора всех атрибутов объекта воедино требуется, по сути, многократный JOIN.
2) Также сильно теряется выразительность из-за отсутствия
статического определения. Это как с языками со статической и динамической типизацией. Языки, где всё однородно, "всё есть объект", тип переменных не требуется определять статически и проч. - удобны иногда, часто позволяют меньше думать (увы) на старте, чтобы потом огрести проблем при росте системы... Потому что однородность, гибкость в системы должна вводиться дозированно - ровно столько, сколько надо. А всё, что можно, нужно стараться выразить явно, статически: в случае с БД - явным набором таблиц с явно описанной структурой, а не неявными связями между перемолотыми атрибутами объектов.
Однако, заметим, конечно, что в области всякого рода PIM (personal information management) как раз наблюдаются факторы к тому, чтобы Вами выбранная модель была удобной и оправданной.
P.S. И, кстати, для тех, кто от реляционной модели оставляет только "одну таблицу" - есть NoSQL-СУБД. Вам прямая дорога в MUMPS/Cache, по ходу дела