ChallengerВели переговоры с заказчиком. Коснулись структуры базы данных.
Спор возник на неожиданном месте.

Структуру в упрощенном виде привожу
таблица 1.
tbX
xID
xName

таблица 2.
tbY
yID
yName

таблица 3.
tbZ
zID
zName

таблица 4(обобщенная).
tbXYZ
xyzid
другие поля
xID
yID
zID

Я привык делать нормализованную структуру, и не задумываться.
...
Дополнительно скажу, что
1. В базе очень много записей.
2. Дублирований полей xName,yName,zName будут часто повторяться


Заказчик настаивает на своем опыте, что будет система тормозить в случае, если структура будет нормализованной (мой вариант). Что при многочисленных выборках, надо делать join 3-x таблиц, что будет тормозить. Итд итп.
Что добавление новых записей сложнее в моем варианте.
1. Непонятно, каким образом будут связываться данные из первых 3 таблиц в четвёртую.
2. Если алгоритм связывания относительно простой, то вполне может быть вариант с одной таблицей, в которой будут находиться все 3 таблицы, благо их структура совпадает. Только добавить поле, определяющее таблицу, что-то типа:
FieldtbIDxIDxName
Собирать же в обобщённый вариант можно с помощью PIVOT или агрегирующих функций.
3. Если возвращать пользователям тысячи и более записей, то "join 3-x таблиц" действительно может составить проблему, впрочем, в таком случае и выборка из одной обобщенной таблицы тоже не спасёт. В противном же случае, когда количество возвращаемых записей относительно невелико, то влияние join может оказаться не столь уж и пагубным.
4. Если заказчик сам всё знает, то может пусть сам и делает ? Иначе может возникнуть ситуация, когда, уступая заказчику, Вы же окажетесь виноватым.

ChallengerChA
1. Непонятно, каким образом будут связываться данные из первых 3 таблиц в четвёртую.
Почему непонятно. Там foreighn key, и отношение один ко многим, что по моему очевидно сходя из названий полей.Слово "обощенная" обескуражило, не понял, что это стандартная "снежинка", таблица фактов, обвешанная справочниками. Оптимизатор MS SQL нормально работает с такой схемой. Конечно, многое зависит от типовых запросов, но "выигрывая" в отсутствии слияний, мы проигрываем в объёмах, и наоборот. Операции IO самые дорогие, поэтому может так случится, что слияние окажется более оптимальным. Судя по размерам, справочники вообще могут не вылезать из ОЗУ, поэтому стоимость слияний будет очень мала, а вот таблицу фактов придется постоянно поднимать с диска(ов), и чем "длиннее" записи, тем больше будет чтений данных. Это может запросто организовать "затык" в дисковой подсистеме, особенно, когда будет много параллельных запросов.

P.S. В конце концов, несложно построить тестовый пример, и по производительности типовых запросов определить, что будет более оптимальным в конкретном случае.