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

Question

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

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

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

Так что мой вопрос ...

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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