Во-первых, я не думаю, что там все параметры произвольные. Всё равно есть какая-то часть, которая имеется у всех объектов. Вот их нужно выделить и хранить в обычных таблицах. А для остальных использвать метод метатаблиц, как тут предлагалось (ID,TypeParam,NameParam,VarStr,VarInt,VarDouble,VarMemo,...).
Если есть возможность, то можно всё хранить в текстовом виде как строки, тогда структура упрощается. Существуют ещё варинаты, когда разные типы хранятся каждый в своей таблице (чтобы место сэкономить). Но с точки зрения обработки это получается очень сложно.

И ещё, для данной задачи я Вам весьма рекомендую сделать не просто список параметров, а ещё и разделы, где эти параметры сгрупированны. Плюс, что-то типа справочника параметров, из которого оператор будет их добавлять в конкретные объекты. Там, естетсвенно, та же система разделов, по которым эти параметры сгрупированы. В справочнике мы храним тип, наименование и значение по умолчанию. Возможно, что ещё и допустимый диапазон значений для данного параметра. Я бы ещё сделал к справочнику третью таблицу (кроме разделов и самих параметров), где бы при необходимости можно было хранить список допустимых или наиболее часто используемых значений, которые пользователь потом сможет выбирать с помощью ComboBox'а. Насколько я знаю эту предметную область (строительство), то там это встречается очень часто. Те же материалы конструкций или диаметры труб, марка бетона, цемента, металла и т.п. Причём тут, опять же, в большинстве случаев достаочно ограничется обычным текстовым представлением.

А я думаю, что тут есть ещё один момент. На самом деле количетсво параметров не такое уж "любое" и бесконечное. Я немного эту предметную область знаю, там действительно параметров много, СНиП'ов всяких полно. Но при всём при этом там тоже есть своя внутренняя структура с конечным числом объектов и их свойств.

То есть, есть ещё варнат, когда мы делаем не просто справочник параметров, а "хранилище" этих параметров. То есть, таблица создаётся не для каждого объекта, а когда новый параметр добавляется в справочник.

Но на самом деле нужно делать прототип и тестирвоать на удобство и быстродействие. Мне приходилось видеть системы с метатаблицами, где к примерно 30 тыс. базовых записей генерилось почти 500 тыс. записей в таблицах параметров. При этом система становилась ну очень сильно тормозной, хотя там что-то такое пытались оптимизировать и практически все операции выполнялись хранимыми процедурами на сервере.

Что касается "много таблиц - плохо", то это связано с той же экономией ресурсов. Когда то это были ограничения на количество одновременно открытых файлов, сейчас попытка сэкономить ресурсы сервера. Ведь сервре, как я понимаю, для каждой используемой таблицы будет собственный объект заводить с буферами, таблицей прав пользователей и т.п.

Во, в правильном направлении разговор пошёл. :)
А то полезли в дебри.

И вообще, если ему не нужен анализ всех этих параметров у объектов, а лишь возможность пользователю что-то такое сохранить, чтобы потом, вызвав объект, посмотреть, то можно вообще всё хранить в текстовом виде. Тогда вся структура упрощается до одной вторичной таблицы, где хранится ID объекта, название параметра и его значение. А уж что там пользователь себе сохранит - дело пользователя.