AndreyG_80Тогда прийдется добавлять столбцы в таблицу,
Очень страшно

AndreyG_80ну и если параметры будут удалятся или менятся - тогда прийдется постоянно в таблицу добавлять и удалять столбцы.
Хм. То есть Вы хотите сэкономить на десятисекундной операции там, где потребуется минимум день работы на прочие действия, связанные с изменением списка параметров. Ценой этого будет кривая структура БД, с решениями типа "текстовый список id через запятые". Логично, черт возьми :))

Если "параметр" - практически виртуальная сущность, такая, что с точки зрения системы существуют просто "тип параметра" и "набор значений этого типа", если в системе не присутствует никакой дополнительной информации, например, дополнительных атрибутов "производителя" или "типа салона" - нужно соответственно проработать хранение параметров и сделать развязку Услуга - Цена - НаборПараметров. Иначе - делайте разные столбцы.. или делайте геморрой.

AndreyG_80Нет, если бы у меня была одна база тогда я добавлял и удалял бы столбцы.
OK, зафиксировали.

AndreyG_80 Но у меня одня центральная база и куча клиентских баз, в которые должня выгружаться услуги с ценами и параметрами, причем в разные клиентские базы должня выгружаться разные услуги, парамеры и цены.
Ну и пусть выгружаются разные услуги, параметры и цены. Все названное - данные. Какое отношение это имеет к структурам? Кому будет плохо от того, что в схеме будет десяток пустых таблиц?

AndreyG_80 Если структура базы и таблицы у меня будут меняться, тогда я во всей этой каше концов не собиру.
Хм. Принцип я уже назвал. Либо все параметры похожи как братья-близнецы - тогда можно и нужно делать универсальную структуру. Либо же они различаются по бизнес-логике - и тогда собирать концы придется при любой реализации; все, что можно сделать - либо сделать эту реализацию удобной, либо добавить своих грабель.

AndreyG_80 Я, тут, обдумываю еще один вариант. Создать таблицу (добавить в таблицу соответствий) в которой хранятся: код услуги, код параметра и цена. В таблице услуг тоже цена услуги. Потом сумировать цену услуги из таблицы услуг и цену по каждому параметру даной услуги. Сумма этого всего и будет являться ценой услуги
Хм. А кто обещал Вам, что в систему не потребуется ввести данные, не ложащиеся в эту схему?

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

Другой вопрос, если описанное Вами совпадает с логикой ценообразования. В этом случае, если заказчик даст гарантию, что цены всегда формируются именно так, так и надо делать.