Всъщност дизайнът, който описахте (обща таблица плюс таблици, специфични за подтипа), се нарича Наследяване на класова таблица .
Наследяване на конкретна таблица ще има всички общи атрибути, дублирани в таблиците на подтипове, и няма да имате таблица на супертипове, както имате сега.
Категорично съм против EAV. Считам го за SQL антипаттерн. Може да изглежда като елегантно решение, защото изисква по-малко маси, но си създавате много главоболия по-късно. Вие посочихте няколко от недостатъците, но има много други. IMHO, EAV се използва по подходящ начин само ако категорично не трябва създайте нова таблица, когато въвеждате нов подтип или ако имате неограничен брой подтипове (напр. потребителите могат да дефинират нови атрибути ad hoc).
Имате много подтипове, но все още краен брой от тях, така че ако правя този проект, щях да се придържам към Наследяване на класова таблица . Може да имате няколко реда от всеки подтип, но поне имате известна увереност, че всички редове във всеки подтип имат едни и същи колони, можете да използвате NOT NULL ако трябва, можете да използвате SQL типове данни, можете да използвате ограничения за референтна цялост и т.н. От релационна гледна точка това е по-добър дизайн от EAV.
Още една опция, която не споменахте, се нарича Serialized LOB . Тоест добавете BLOB колона за полуструктурирана колекция от персонализирани атрибути. Съхранявайте XML, YAML, JSON или ваш собствен DSL в тази колона. Няма да можете лесно да анализирате отделни атрибути от този BLOB със SQL, ще трябва да извлечете целия BLOB обратно в приложението си и да извлечете отделни атрибути в кода. Така че в някои отношения е по-малко удобно. Но ако това удовлетворява вашето използване на данните, тогава няма нищо лошо в това.
