问题标签 [maintainability]

我有一个一般的数据库设计问题：什么时候创建一个新数据库而不是向现有数据库添加新表更好？该问题与设计/可维护性以及性能问题有关。

背景：我们通过每晚将数据导入我们称为 RM2 的数据库来镜像客户的主表。一些新的（ASP.Net-）项目也需要访问这些数据，现在我想知道是否应该为每个项目创建新数据库或将它们的表与 RM2（当前大小：37991.94 MB）合并。

这应该在数据库中表示为 1 个表还是 3 个表？我和我的朋友对此有不同的看法，所以我想看看对此的一般看法。（也许这应该是对任一解决方案的投票？）

1表方法：

优点：

• 性能（一个插入而不是两个，FK 检查，无连接）
• 可能占用更少的空间（额外的表有开销 + 索引 + 额外的 ID 字段）
• 一张桌子而不是三张
• 仅针对 2+3 个字段（或什么？）

缺点：

• 可为空的字段
• 可能额外的“类型”列（可以跳过）
• 打破 3NF (?)

利弊请及个人意见。:)

编辑：我尝试通过使用与实际使用不同的实体来简化示例，因此任何更改模型的建议都不会真正帮助我。即请更多地关注技术方面而不是领域模型。

我已经看到了几种用于“克服” SQL Server 中缺少常量的模式，但它们似乎都不能同时满足性能和可读性/可维护性的问题。

在下面的示例中，假设我们的表中有一个完整的“状态”分类，选项似乎是：

• 只是硬编码，可能只是“评论”状态

• 使用状态查找表，然后加入该表，以便WHERE子句引用友好名称。

子查询：

或加入

• 定义了一堆标量 UDF，它们返回常量，即

进而

（IMO 这会在数据库中造成大量污染——这在 Oracle 包包装器中可能没问题）

• And similar patterns with Table Valued Functions holding the constants with values as rows or columns, which are CROSS APPLIED back to [Table]

How have other SO users have solved this common issue?

Edit : Bounty - Does anyone have a best practice method for maintaining $(variables) in DBProj DDL / Schema scripts as per Remus answer and comment?

这是一个整洁的有据可查的正则表达式，易于理解、维护和修改。

但是你如何处理这些？

是否有某种美化器可以理解它并描述其功能？

我们的代码很烂。实际上，让我澄清一下。我们的旧代码很糟糕。它很难调试，并且充满了很少有人理解甚至记得的抽象。就在昨天，我花了一个小时在一个我工作了一年多的领域进行调试，发现自己在想，“哇，这真的很痛苦。” 这不是任何人的错——我相信一开始这一切都说得通。最糟糕的部分通常是它只是工作......只要你不要求它做任何超出其舒适区的事情。

我们的新代码非常好。我认为我们在那里做了很多好事。它清晰、一致且（希望）可维护。我们已经运行了一个 Hudson 服务器以进行持续集成，并且我们已经开始使用单元测试套件。问题是我们的管理层专注于编写新代码。没有时间给旧代码（甚至旧的新代码）它迫切需要的 TLC。在任何特定时刻，我们的 scrum backlog（针对 6 名开发人员）都有大约 140 项和大约十几个缺陷。这些数字变化不大。我们正在以尽可能快的速度添加东西。

那么我能做些什么来避免陷入旧代码深处的马拉松式调试会话的头痛呢？每个 sprint 都充满了新的发展和惊人的缺陷。具体来说...

• 我可以做些什么来帮助维护和重构任务获得足够高的优先级以进行工作？
• 您是否采用了任何特定于 C++ 的策略来帮助防止新代码如此迅速地腐烂？

几个月前我正在编写一堆代码，现在我正在向其中添加内容。我意识到我写了一堆函数，这些函数来自一个类，其中大约 2/3 的函数是抽象的，剩下的 1/3 是虚拟的。

我非常讨厌看到：

当我为基类得到这个时：

并且不愿意结束：

然后想知道为什么有些东西不起作用。

我喜欢使用抽象函数，因为编译器会让你知道你是否可能因为你没有实现某些函数而出现抽象错误。

我的问题是，因为我仍然是一个相对较新的 Delphi 程序员，并且在 8 年后我从来没有维护过任何东西，是否值得花时间以这种方式修剪你的代码（即删除刚刚继承的函数）并将您的基类函数从抽象更改为具体）

我一直在玩一些 mvc 框架实现的“模块”概念，它似乎是一个很好的解决方案，还有 TDD，但我认为必须有更多的东西，比如我错过的设计模式（我只知道一个很少），这将让我构建可以无限制地（在代码中）增长的应用程序。

有什么想法吗？

编辑：关于模块的另一个好处是它们可以以独立于应用程序的方式构建，因此它们可以被重用。

由于长期使用 SQL2000，我并没有真正接触过公用表表达式。

我在此处 (#4025380)和此处 (#4018793)给出的答案与流程背道而驰，因为他们没有使用 CTE。

我很欣赏递归它们是 beez kezez，并且有一些查询可以通过它们的使用大大简化，但是在什么时候它们的使用只是轻浮的？与子查询或联接相比，它们是否具有很大的性能优势？他们真的简化了代码并使其更易于维护吗？

简而言之，什么时候最好使用 CTE 而不是“较少”的语法。

我正在开发一个（vb.net/asp.net）项目，该项目使用接口提供依赖注入。但对我来说，感觉就像代码的可维护性已经被扼杀了。当我想通读代码时，我不能简单地跳转到使用的相关类的代码。我看到的只是接口，所以我必须通过项目来找出哪些类正在执行实现。这真的伤害了我的工作效率。

是的，我知道我现在可以使用各种替换类来实现接口。但是，例如，我知道我不会很快更改我的数据源——我不需要启用将其换出的能力。所有这些依赖注入对我来说似乎都是多余的（事实上，它存在的唯一真正原因是支持用于单元测试的模拟类）。我实际上已经阅读了几个地方，状态 DI 实际上更利于可维护性。但这假设您已经知道所有内容在哪里，并且您知道需要更新哪个类。找出在哪里看是杀死我的部分。

所以，我的问题是：有没有更好的方法来遍历代码？有没有更好的方法让代码更易于维护？我们只是做错了吗？或者这是课程的标准杆？

在我们的组织中，我们正在维护一个 VS 2005 网站，该网站严重依赖于强类型表适配器和数据表。毋庸置疑，这是一个可维护性的噩梦，原因有很多：

• 要生成新的表适配器，我们需要连接到 MSSQL2005 和更少的数据库，因为我们将数据库升级到 MSSQL2008，这真是地狱。
• 我们在 2010 年底，我们真的很喜欢在这个项目中使用 VS2010，但是升级它却编译失败。我想我们可以努力让它发挥作用，但我们宁愿一起摆脱这种可怕的技术。
• 生成的代码很大而且看起来很糟糕，我怀疑没有像 LSD 这样的东西任何人都可以理解它。

在这一点上，我们真的想做最少的事情来帮助我们摆脱这些表格适配器，因为我们没有时间，而且它不是管理的优先事项，因为它“有效”。因此，建议 nHibernate 是一场我们可能不会随之而来的革命。

先感谢您。