Отношения SQL Server похоронены в хранимых процедурах, а не в схеме

Question

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

Знание того, как эти таблицы связаны друг с другом, подразумевается в логике хранимых процедур, а не явно в схеме. Мы рассматриваем возможность изменить это.

Первый шаг - это понять неявные отношения и задокументировать их.

Итак, мой вопрос...

Каков наилучший способ извлечь эту скрытую информацию, если не считать, что все хранимые процедуры выглядят гладко? Я рассмотрю любые инструменты, напишу свой собственный SQL для опроса системных таблиц или использую модель SQL-DMO - или фактически что-нибудь под солнцем, которое позволяет компьютеру выполнять больше работы, а я - меньше.

Answer 1

Если отношения идентифицируются только объединениями в SP, то вам не повезет, если вы автоматизируете их.

Может быть целесообразно захватывать запросы с помощью профилировщика, чтобы сначала найти наиболее частые объединения.

Answer 2

Когда дело доходит до рефакторинга, я старая школа:

1. Документируйте, что у вас есть, используйте визуальный инструмент.
2. Опишите - в письменной форме - бизнес-модель, которую захватывает эта база данных.
3. Подберите сущности из существительных описания и имеющейся у вас схемы.
4. Создать новую модель ER; проконсультируйтесь с бизнесом, пока у него.
5. Создать новую БД на основе ER
6. Данные ETL передаются в новую базу данных и тестируются.

Answer 3

Ты можешь использовать sys.sql_dependencies узнать, от каких столбцов и таблиц зависит SP (помогает, если вы этого не делаете SELECT * в ваших ИП). Это поможет вам получить список кандидатов по крайней мере:

referenced_major_id == the OBJECT_ID of the table
referenced_minor_id == the column id: COLUMNPROPERTY(referenced_major_id,
                                                       COLUMN_NAME,
                                                       'ColumnId')

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

SELECT *
FROM    INFORMATION_SCHEMA.ROUTINES
WHERE   OBJECTPROPERTY(OBJECT_ID(QUOTENAME(ROUTINE_SCHEMA) + '.'
                                 + QUOTENAME(ROUTINE_NAME)),
                       N'IsSchemaBound') IS NULL
        OR OBJECTPROPERTY(OBJECT_ID(QUOTENAME(ROUTINE_SCHEMA) + '.'
                                    + QUOTENAME(ROUTINE_NAME)),
                          N'IsSchemaBound') = 0