Yar*_*rik 8 sql database sql-server refactoring
我正在研究一个传统的小型企业自动化系统(库存,销售,采购等),它有一个由SQL Server 2005托管的单个数据库和一堆客户端应用程序.主客户端(由所有用户使用)是MS Access 2003应用程序(ADP),其他客户端包括各种VB/VBA应用程序,如Excel加载项和命令行实用程序.
除了60个左右的表(大多数是3NF)之外,数据库还包含大约200个视图,大约170个UDF(主要是标量和表值内联的),以及大约50个存储过程.正如您可能已经猜到的那样,所谓的"业务逻辑"的某些部分被封装在大量的T-SQL代码中(因此被所有客户端共享).
总的来说,系统的代码(包括T-SQL代码)组织得不是很好,可以说是非常重构的.特别是,大多数表的模式都适用于所有类型的重构,小型(如列重命名)和大型(如规范化).
FWIW,我有很长很好的应用程序开发经验(C/C++,Java,VB和诸如此类的东西),但我不是DBA.所以,如果这个问题看起来很愚蠢,现在你知道为什么会这样.:-)
在考虑重构所有这些混乱时(当然是以和平方式),我想出了以下想法:
对于每个表,创建一个"包装器"视图,其中(a)具有该表具有的所有列; (b)在某些情况下,根据表的"实际"列有一些额外的计算列.
这种附加计算列的典型(尽管是简单的)示例是从产品的常规价格和折扣得到的产品的销售价格.
重新组织所有代码(T-SQL和VB/VBA客户端代码),以便只有"包装器"视图直接引用表.
因此,例如,即使应用程序或存储过程需要从表中插入/更新/删除记录,它们也会针对相应的"表包装器"视图执行此操作,而不是直接针对表.
因此,基本上这是关于通过视图将所有表与系统的其余部分隔离开来.
这种方法似乎提供了很多好处,特别是从可维护性的角度来看.例如:
当要重命名表列时,可以在不重写所有受影响的客户端代码的情况下完成.
实现派生属性更容易(比使用计算列更容易).
您可以有效地为列名称添加别名.
显然,所有这些好处都必须有一些代价,但我不确定我是否看到了潜伏在那里的所有渔获物.
有人在实践中尝试过这种方法吗？有哪些主要缺陷？
一个明显的缺点是维护"包装"视图与其相应表同步的成本(表中的新列也必须添加到视图中;从表中删除的列也必须从视图中删除;等等).但是这个价格似乎很小,而且可以使整个代码库更具弹性.
有没有人知道任何其他更强的缺点？
例如,使用所有这些"包装"视图而不是表格很可能会对性能产生一些不利影响,但这种影响是否足以让人担心呢？此外,在使用ADODB时,即使只基于少数连接表,也很容易获得不可更新的记录集.那么,"包装"观点是否会使事情变得更糟？等等等等...
任何评论(特别是共享的实际经验)将不胜感激.
谢谢!
PS我接下来讨论了"包装"视图的想法:
该文章建议避免上述方法.但是......我在文章中没有看到任何反对这个想法的充分理由.恰恰相反,在其创建视图的充分理由列表中,几乎每个项目都是为什么为每个表创建"包装"视图(特别是在遗留系统中,作为重构过程的一部分)如此诱人的原因).
这篇文章真的很古老(1999),所以无论什么理由都好,那么现在可能已经不再好了(反之亦然).使用最新版本的SQL Server和MS Access,听到最近考虑过甚至尝试过这个想法的人真的很有意思......
Ste*_*owe 10
在设计数据库时,我更喜欢以下内容:
这允许DBA直接使用表(添加列,清理内容,注入数据等)而不会干扰代码库,并且它使代码库与对表所做的任何更改(临时或其他)隔离开来
以这种方式做事可能会有性能损失,但到目前为止它们并没有太大意义 - 绝缘层的好处已经过几次救命
| 归档时间： |
|
| 查看次数： |
4361 次 |
| 最近记录： |