Как вы документируете структуру своей базы данных? - программирование
Подтвердить что ты не робот

Как вы документируете структуру своей базы данных?

Многие системы баз данных не допускают комментариев или описаний таблиц и полей, поэтому как вы собираетесь документировать цель таблицы/поля, кроме очевидного наличия хороших соглашений об именах?

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

Я знаю, что многие люди используют диаграммы UML для визуализации базы данных, но я редко встречаюсь, если когда-либо видел диаграмму UML, включая комментарии к полям. Тем не менее, у меня есть хороший опыт использования комментариев внутри файлов .sql. Недостатком этого подхода является то, что он требует, чтобы файлы .sql обновлялись вручную по мере изменения структуры базы данных с течением времени, но если вы это сделаете, вы также можете получить ее под управлением версии.

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

Как вы решили эту проблему в прошлом? Какие существуют методы и каковы различные плюсы и минусы, связанные с ними? Как вы хотели бы, чтобы это было разрешено в "идеальном мире"?

Обновление

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

4b9b3361

Ответ 1

MySQL позволяет комментировать таблицы и строки. PostgreSQL также. Из других ответов Oracle и MSSQL также имеют комментарии.

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

Ответ 2

Поздно, но, надеюсь, полезно... Вот процесс, который мы использовали при разработке относительно большой базы данных (всего около 100 таблиц и около 350 объектов)

  • Разработчики должны были использовать расширенные свойства для добавления сведений обо всех объектах.
  • Администраторы отклонили любой DDL, у которого не было расширенных свойств.
  • Инструмент сторонних разработчиков использовался для автоматического создания визуальной документации через интерфейс командной строки каждый день. Мы использовали ApexSQL Doc, и он работал отлично, но я также успешно использовал SQL Doc от Red Gate в другой компании.

Этот процесс обеспечил, чтобы все объекты были задокументированы и документально обновлены.

Нелегко было заставить разработчиков писать хорошие комментарии последовательно;)

Ответ 3

SQL Server имеет расширенные свойства, которые могут позаботиться об этом.

В этой статье описывается, как настроить их в SQL Sever http://www.developer.com/db/article.php/3677766

Ссылка MSDN

Он может использоваться совместно с RedGate SQL Doc для создания хорошего словаря данных.

Ответ 4

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

Ответ 5

В какой-то момент я написал базовый синтаксический анализатор SQL, который будет анализировать инструкции CREATE TABLE и выделять специально отформатированные комментарии. Затем они были обработаны после обработки в источнике LaTeX и переданы в PDF. Это было вдохновлено Javadoc и использовалось для создания документации для Этот продукт. Впоследствии функция хранилища данных была встроена в диспетчер склада, а модифицированная версия генератора LaTeX использовалась для отображения словаря данных из диспетчера хранилища.

В другом проекте я использовал Visio - версия, которая поставляется вместе с Visual Studio Enterprise Architect, будет перерабатывать базу данных. SQL, сгенерированный таким образом, имел комментарии таблицы и столбца, представленные в строках комментариев, которые были довольно просто проанализированы. Инструмент, который я написал, сгенерировал MIF файлы, которые были включены в спецификационный документ, созданный с помощью FrameMaker.

Если у вас есть инструмент репозитория, например Powerdesigner, вы можете поддерживать в нем модели данных и получать отчеты о репозиториях, включающие документацию Вы вошли. Если вам нужна более глубокая интеграция вашего словаря данных с функциональными спецификациями (весьма полезна для систем хранилищ данных, где ETL сложна и включает в себя значительные вычисления производных значений), вы все равно можете извлечь метаданные и написать утилиту для создания чего-то, что будет интегрировать данные словарь в документ спецификации. Это также позволяет перекрестно ссылаться между элементами словаря данных и другими документами спецификации и генерировать индексы, которые охватывают определения словаря данных и соответствующую документацию, такую ​​как спецификация того, как что-то вычисляется с примерами.

Ответ 6

Мы написали документ, в котором перечислены таблицы, поля и все. Это подтверждается диаграммой, которая показывает, как все связывает/связывает друг с другом. Это довольно простой документ на самом деле, просто загрузка таблиц с именем поля > Тип данных > Цель

Ответ 7

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

Большинство администраторов. инструменты для Firebird позволяют редактировать эти описания, и есть некоторые специализированные инструменты (например, IBDesc, например), которые создают хорошие отчеты HTML или PDF, которые вы можете распечатать (для некоторых или всех таблиц) легко.

Ответ 8

Это очень упрощенный подход, но я использую пару страниц вики: один с mysqldump базы данных и один написанный в чуть более английском формате.

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

Ответ 9

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

Использование SQL COMMENT - еще одна возможность. Хорошая вещь с ними в том, что они всегда с вашими объектами, подкреплены ими и т.д. Плохо то, что они более ограничены (например, по длине).

Ответ 10

Поскольку мы используем Rational Software Architect, мы используем его функции обнаружения данных для документирования наших баз данных, а затем аннотируем их оттуда.

Ответ 11

В Oracle вы можете прокомментировать таблицы и сохранить их в словаре данных.

Тем не менее, я храню все мои таблицы, столбцы, комментарии индекса в очень старой версии ERWin. Это главный источник истины и генерирует DDL для создания таблиц и т.д. Оттуда я могу извлечь его в текстовый документ или PDF.

Ответ 12

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

Я сохраняю отдельную схему таблицы в управлении версиями, используя следующую команду:

mysqldump --no-data --tab=./tables dbname

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

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