【问题标题】:What are the Best Practices to follow while creating a data-dictionary?创建数据字典时要遵循哪些最佳实践?
【发布时间】:2009-10-15 17:02:15
【问题描述】:

我有多个应用程序使用的大型复杂 SQL Server 2005 数据库。我想创建一个数据字典,不仅可以维护我的数据库对象,还可以将它们与使用特定对象的应用程序交叉引用。

例如,如果一个存储过程被 15 个不同的应用程序使用,我也想记录这些附加数据。

要获得高效且可扩展的数据字典,需要牢记哪些关键要素?

【问题讨论】:

    标签: sql-server-2005 data-dictionary


    【解决方案1】:

    所以,我最近帮助为一个非常大型产品构建了一个数据字典。我们正在处理使用变更请求流程记录超过一千张表格。如果您愿意,我可以将我们使用的电子表格的删减版发送给您。基本上,我们捕获了以下内容:

    • 列名
    • 数据类型
    • 长度
    • 刻度(用于小数)
    • 该列是为应用程序自定义还是默认列
    • 该列用于哪些应用程序/组件
    • 释放列被引入
    • 业务定义

    我们还收集了有关谁请求添加的信息、他们的联系信息等。我们的主要关注点是业务定义,并清楚地确定使用或创建列的原因。

    我们的解决方案中没有存储过程,但请记住,这些很容易添加到系统中。

    我们将 Access 用于前端,尽管 SQL Server 在后端。使用我们已经构建的模式,我们可以轻松构建丰富的用户界面,而无需做太多工作。

    希望这可以帮助您入门 - 如果您还有其他问题,请随时提出。

    【讨论】:

      【解决方案2】:

      我一直很喜欢在 SQL Server 中使用“扩展属性”来存储这种元数据。通过这种方式,每个对象的描述与对象一起存在,并且任何有权访问数据库本身的人都可以访问。我确信还有一些工具可以读取这些扩展属性并将它们转换为格式良好的文档。

      就“可扩展性”而言,我不知道与添加大量数据作为扩展属性相关的任何问题;或者我应该说我从来没有遇到过任何问题。

      您可以使用 SQL Server Management Studio 的“property”对话框为每个表/proc/function/etc 设置这些扩展属性,也可以使用“sp_addextendedproperty”。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2019-01-01
        • 1970-01-01
        • 2011-07-15
        • 1970-01-01
        • 2020-06-11
        • 1970-01-01
        • 2010-10-15
        • 1970-01-01
        相关资源
        最近更新 更多