Вы создаете словарь данных?

Question

Вы создаете словарь данных? Если да, то как?

Я использую расширенные процедуры в SQL Server 2005 для хранения информации о таблицах и полях. У меня есть некоторые запросы, которые создают словарь из них, но это ... meh. У вас есть конкретный запрос или инструмент, который вы используете? Вы создаете его из диаграмм базы данных?

Googling для «SQL-сервера данных» предлагает множество запросов, но все они одинаково привлекательны. То есть хорошие начальные точки, но не готовность к производству.

Answer 1

SchemaSpy это действительно хороший инструмент, который может перепроектировать описание базы данных. Это включает в себя:

• ERD
• Список таблиц, столбцов и ограничений
• Набор предупреждений о БД anomalied (например, таблицы без индексов)

Answer 2

Я генерирую его из INFORMATION_SCHEMA просмотров плюс другие таблицы метаданных, которые являются специфичными для приложения.

Я также использую подстановочный поиск INFORMATION_SCHEMA.ROUTINES, чтобы отслеживать шаблоны использования внутри кода и идентифицировать неиспользуемые столбцы и таблицы.

Эта статья как раз появился в одном из моих лент новостей: http://www.mssqltips.com/tip.asp?tip=1619

Answer 3

Мы генерируем dictionnary базы данных на стороне developper данного приложения. У нас хорошая процедура, использующая ADODB-соединение + ADOX-объекты и коллекции. Эта процедура будет просматривать все таблицы в базе данных. Следующие основные данные собираются:

1. TableName
2. ColumnName
3. ColumnType
4. ColumnSize
5. bool_ColumnIsThePrimaryKey
6. bool_ColumnHasReferentialIntegrityConstraint

Вы также можете следить за значения полей по умолчанию, и т.д.

Затем можно, например, на:

• проверки в сколько столов мое поле currency_id (первичный ключ таблицы Tbl_currency) упоминается, и если ссылочная целостность каждого время должным образом реализованы (мы очень часто создаем поле без , осуществляя соответствующие правила ...).
• Убедитесь, что области аналогичных логических типов (например, "description" полей) имеют аналогичные данные тип/размер. Ничто так не расстраивает , что с полем item_Description nvarchar(50) в таблице, а также document_Description ntext в другом стол!
• т.д.

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

Столбец dictionnary/отчет может быть сформирован из этих данных через

SELECT DISTINT columnName FROM Tbl_Column 

Answer 4

Лично я предпочитаю, чтобы создать словарь данных, а база данных разрабатывается. Конечно, это не всегда вариант ...

Я думаю, что ответ зависит от текущего состояния базы данных? Это сделано и в производстве? Вы еще не начали на нем? (и т. д.)

В прошлом, как и Cade Roux, я вытащил информацию из Information_SCHEMA в базу данных доступа. В настоящее время разработчики иногда добавляют информацию о различных таблицах, столбцах, хранимых процедурах, функциях и т. Д. В базу данных Access. Внутри базы данных Access мы создали отчеты для вывода аккуратно выглядящего «Словаря данных».

Это не самый эффективный способ создания словаря данных, но при условии, что проект прошел 3 года без каких-либо признаков словаря данных, это то, что мы должны были сделать.

Так что в конечном итоге ответ на это зависит от состояния вашей базы данных.

С наилучшими пожеланиями,
Frank

Answer 5

Мы используем расширенные свойства.

Для их использования используется sys.extended_properties Это упрощает процесс.

Мы также используем Red Gate SQL Doc

Answer 6

Мы написали свой собственный словарь данных утилита, которая используется расширенные свойства, но когда мы нашли инструмент RedGate, мы отказались от нее для их инструмента. Работали отлично для нас! Думаю, это помогло нам уже иметь описания полей и таблиц в расширенных свойствах. Не рекламировать компанию, но у них есть 14-дневная бесплатная пробная версия. Это стоит посмотреть. http://www.red-gate.com/products/SQL_Doc/index.htm

Answer 7

Я использую этот инструмент (с открытым исходным кодом): http://www.codeplex.com/datadictionary. Вся информация, которую я создаю, добавляется в расширенные свойства базы данных.

Answer 8

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

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

Техника:

• Расширенные свойства во всех объектах + third party tool для создания DOCS

Что было документировано:

• Все таблицы и некоторые столбцы (мы добавлены хорошие описания для всей таблицы s, чтобы действительно убедиться, что это ясно, что таблица о)

• Все просмотров - описания о том, почему было создано представление, какие таблицы включены в данные и такие, а также когда использовать

• Все сохраненные процедуры - во время процесса мы обнаружили, что у нас было много повторяющихся хранимых процедур (разработчики не потрудились увидеть, существует ли proc, чтобы они создали новые)

• Все UDF и некоторые другие объекты, но не все (у нас действительно не было необходимости документировать триггеры)

Что мы в итоге сделали, так это то, что наш администратор баз данных отклонил все обновления DDL, которые поступают от разработчиков, если нет расширенных свойств.

У нас также есть запланированная задача по автоматическому повторному созданию документации каждые 2 недели.

Answer 9

Мне повезло с SQL Data Dictionary.