причесываю oltp. добавляю в справочник в качестве ПК суррогатный id (старый составной ЕК при этом становится просто уникальным индексом), чтоб не хранить в связанном журнале составной ЕК объектов справочника. далее навешивается соответствующий ВК

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

вторая сложность в том, что воссоздать реальную нагрузку боевого сервера сейчас нет возможности. есть ли способы как-нибудь прикинуть, рассчитать изменение нагрузки без стенда (смертельно/не смертельно)? и просто посоветуйте по теме, как сделать для старых клиентов операцию максимально незаметной

sql 2008 sp2 ent/express