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

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

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

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

Мы генерируем словарь базы данных на стороне разработчика приложения. У нас есть хорошая процедура, использующая соединение 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 или что-то еще) и сохраняются для дальнейшего использования.

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

SELECT DISTINT columnName FROM Tbl_Column

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

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

Раньше, как и Кейд Ру, я извлекал информацию из INFORMATION_SCHEMA в базу данных доступа. В настоящее время у нас есть разработчики, которые иногда добавляют информацию о различных таблицах, столбцах, хранимых процедурах, функциях и т. д. В базу данных Access. Внутри базы данных Access мы создали отчеты для вывода аккуратной распечатки «Словаря данных».

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

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

С уважением,
откровенный

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

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

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

Для их чтения мы используем sys.extended_properties Это значительно упрощает жизнь.

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

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

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

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

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

Техника:

• Расширенные свойства во всех объектах + сторонний инструмент для создания документов

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

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

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

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

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

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

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

Мне повезло с Словарь данных SQL.