Yura Peregon Схема довольно громоздкая и плохо масштабируемаяВ упор не вижу плохой масштабируемости: новый объект -> новая клиентская программа (надо же как то новые данные вводить, искать, отображать) -> новая база (с доп таблицами или полями).
Неприятно только что вместо одной новой сущности - клиентской программы, добавляется ДВЕ - программа и база и стало быть ЧЕТЫРЕ возможных состояния. С другой стороны по статистике данные живут дольше программ.
Yura Peregon Может лучше в одной таблице держать XML со специфическими параметрами, насколько пробленое такое решениеЕсли все специфические данные читаются/пишутся только вместе, одним большим массивом то смысл есть. Однако поиск по определенному полю - уже проблема. Оно конечно решается, но решается удвоением хранения, усложнением обработки и т.д. А если возникнет задача обработки типа у всех работ у которого метраж кабеля больше 50 установить в 50 то тут с XML совсем грустно.
Есть еще EAV - то еще убожество с совершенно убитой производительностью
авторТоесть фактически убить типизацию как таковую?Если сделать три поля (для даты, числа и строки) плюс ограничение, что заполнено должна быть только одно, то типизация останется. Но повторюсь EAV - зло.
Yura Peregon А если понадобиться (в качестве параметра таблица, такое уже есть - сейчас это Т001Details) тогда как?Это надо что-то в консерватории править.

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