重新设计数据库的最佳实践

在为应用程序设计数据库时，我知道一些通用的最佳做法，但是重新设计呢？

我正在一个负责重新设计内部业务应用程序的团队中，尽管尽管我说的是“内部”，但不幸的是，我仍然有很多很多层次的人无法与系统的实际用户联系。

当前程序以Oracle Forms形式存在，散布在许多非规范化表中，有时还有多个几乎重复的表，它们在彼此的数据上略有不同。约束通常以存储过程执行不力的形式出现。甚至类型似乎也没有正确存储。我遇到了各种各样的错误数据，Oracle似乎忽略了这些错误数据，但这些数据适合SQL Server的“导入/导出向导”。（例如，两位整数不构成完整的日期时间！）

原始程序可能要追溯到二十年前，所有原始开发人员都已经退休很久了，以至于这里的老年人也不知道他们是谁。结果，实际上也没有任何干净的要求—我们只应该复制现有应用程序的功能并保留其现有数据。

重写的最终结果将是在ASP.NET上运行的基于Web的版本，后端是MS SQL Server。

我的另外两个开发团队成员都比我大得多，都具有商业/ MIS背景，而我的则是CS。高级成员的经验几乎完全是Oracle表格，而其他成员则主要在Visual Basic中完成业务应用程序工作。尽管我的数据库背景仅限于为MySQL或SQLite中的项目设计新数据库，主要是针对我的本科课程，但我似乎是唯一拥有实际设计数据库经验的人。

我已经用C＃编写了一个小程序，该程序将所有现有数据读取为中性格式，可以重新广播并放置到新数据库中。我计划在设计目标数据库之后编写加载代码，以便可以在新的规范化表中正确分割数据，以正确的顺序添加数据以遵循新的约束，等等。然后可以再次运行同一程序将生产数据复制到真正新部署的完成的重新设计中。剩下的主要工作是对数据库进行实际的重新设计。

所以我的问题的核心：从现有应用程序的数据库级别进行重新设计的最佳实践是什么？

我认为您已经知道如何规范化数据库。

您需要的是在将所有软件移至新数据库时将风险最小化的策略。

我的建议是更多的工作以降低风险为代价。

规范化数据库，并创建一个过程，以使用原始数据库中的数据填充规范化的数据库。原始数据库将是用于插入，更新和删除的数据库。仅在转换期间，规范化数据库将成为查询数据库。

您的填充过程将必须与查询数据一样频繁地运行。如果可以接受一天的旧数据，则可以运行一个每晚填充过程。如果需要更多当前数据，则必须运行一个连续的填充过程。

构建指向新的规范化数据库的新ASP.NET系统的查询部分。

新系统的查询结果应与原始系统的查询结果进行比较。

您可以在此时停止。那是业务决定，而不是技术决定。

您可以在新的ASP.NET系统中随意创建新的插入/更新/删除功能。创建新功能时，您将关闭原始系统中对应的部分。在某些时候，原始系统什么都没有保留。

以这种方式进行转换的优点是通过首先构建查询部分来降低风险。与嵌入/更新/删除功能中嵌入的业务逻辑相比，查询功能通常比较简单。

您一次转换一个插入/更新/删除功能。如果对业务逻辑有误解，可以在用户使用原始系统时解决。

不用说，您的填充过程最好绝对一致。

试图说服他们将新系统的开发工作外包给外部公司，因此，许多优秀的开发公司拥有比有限的团队更快，更好地正确开发应用程序的资源。一家优秀的开发公司还能够迫使您的上级执行他们可能做的事情（如果您要求做的事情），该公司的PM获得很多钱来开发应用程序，这会吸引更多用户参与比管理权限以下级别的IT人士要安排这些事情。

预先花费很多钱，但是将花费大量时间来拥有适当的资源来开发和实施。如果您确实设法提出了RFP，那么我敢打赌，您得到的投标表明您试图做的事情比您的经理所意识到的要复杂得多。

使用所需的数据类型设计所需的规范化数据库。然后最困难的部分是迁移数据。首先，您需要制定计划，规划如何从旧映射到新映射，以及如何处理不符合新结构的数据。例如，如果您没有适当的完整性约束，那么您现在可能无法识别的数据。您可能只希望不移动该数据，或者可能需要移动它，但将其附加到名为“未知”的新父记录中。如果日期不是真正的日期，那么在迁移时是否可以在字段中输入null？您将需要回答这些问题。我会建议您让一些开发人员在gui上进行更改以使用新的数据库结构，而另一些开发人员则在迁移上进行严格的工作。迁移是一项艰巨的任务，它将花费很多技巧和大量时间。不要把它当作事后思考。

由于使用的是SQL Server，因此可以通过SSIS进行实际的迁移。

创建一组良好的测试用例，以便您可以比较旧系统的结果与新系统的结果。

由于您拥有这么多年的数据，因此您可能希望分两部分进行迁移。首先迁移大多数数据，然后在需要上线时，仅迁移更改的数据。当然，您将需要在数据库上放置控件，以便能够找到您可能尚未拥有的更改数据。如果您要归档一些数据，那么此时您也可以考虑。

由于支持和进一步开发了一些作为MS Access文件（.mdb）诞生的遗留应用程序，因此我几乎每天都要面对数据库架构的重新设计，然后逐渐发展为现在拥有位于MS SQL上的数百个表的大型数据库服务器，但仍具有原始设计的“婴儿病”。以下是一些对我有用的实践：

尝试最小化数据库架构的公共可用表面。

这意味着您应该尝试设计一些可用于外部应用程序的公共API。我通常尝试将静态数据实现为视图（即使它们仅基于单个表），而将动态数据实现为参数化视图或存储过程。对于仅单个值就足够的数据查询，也可以使用标量函数。

对于外部应用程序（通过ORM或直接），只有这些（视图，存储过程和标量函数）可见，并用于所有CRUD操作。然后，此架构被完全冻结，而在内部您可以更改基础表，改进过程等。这不会破坏与应用程序的兼容性。

尝试针对实际标准进行优化，而不是针对书本中的标准进行优化。

在每本有关数据库设计的书中，规范化都是一个大主题。但是在现实生活中，有些情况下规范化不会给您带来太多，甚至不会减慢数据库的速度，例如，如果您有一些重复的数据，但是重复的百分比很低等。我不反对规范化，我在这里要说的是，您必须以一些怀疑和审慎的态度来解决它。

记录性能分析会话并进行分析。

仅基于数据库架构的数据库重新设计不完整。查看数据库的动态情况，尝试查找负载测试期间的瓶颈并解决这些瓶颈。如果是MS SQL Server，则有一个特殊的Tuning Advisor，它可以根据记录的活动跟踪生成一些建议。

这是我的答案：

1. 首先，尽可能多地了解当前的数据库系统。您需要了解这些系统的所有用途以及用户。您需要知道系统的所有源以及它可能充当其源系统的系统。

2. 您需要确定系统的所有不同用途，无论是用于操作还是用于报告，或同时用于两者。确定可能正在使用数据库的应用程序和上游系统。这样，您将知道当前数据库中已过时且不再需要的元素。

3. 还分析并了解当前的ETL过程，该过程将数据加载到数据库并从数据库中提取数据。

4. 了解数据库的所有数据元素，以及是否可以构建一个框矩阵来帮助您识别重复的元素。

5. 获得了所有信息之后，就可以像在第一次设计数据库时一样使用您在需求收集过程中收集到的信息来进行重新设计。

6. 祝好运！