代码优先与数据库优先

在设计和创建要使用的软件时，通常会先设计和创建后端SQL表，然后再进行实际编程。我目前正在从事的项目让我感到困惑。这可能是由于缺乏良好而可靠的要求所致，但是不幸的是，这次我对此几乎无能为力。这是一种“随它去吧”的情况，但是我离题了。

我正在考虑将工作流程从头开始，并首先创建UI和数据模型类，以期解决该问题将使我清楚我的数据库架构最终将是什么样。这是一个好主意吗？我很担心自己最终将获得一个UI，但仍然不知道如何构造数据库。

如果有人好奇，我将SQL Server用作后端，将MS Access用作前端应用程序。（访问也不是我的选择...所以请不要对此感到讨厌。）

首先是流程，还是流程使用的数据？我知道这是一个“鸡还是蛋”的问题，但是对于软件来说，我相信这是一个过程。

例如，您可以一次仅实现一个内存持久性（或任何易于实现的）来实现一个用例，从而逐步建立数据模型。当您感觉到已经实现了足够的用例来概述基本实体时，可以用真实的数据库替换内存中的持久性，然后继续进行改进，一次只使用一个用例。

这将焦点从数据库中移出，并将其移至问题的核心：业务规则。如果从实施业务规则开始，那么最终（通过非常类似于Natural Selection的过程）将发现企业真正需要哪些数据。如果您从对数据库建模开始，却没有反馈到是否确实需要该数据（或采用这种格式，或处于那种规范化水平，等等...），那么您要么最终会在模式（如果业务已经在运行，则可能需要繁重的迁移过程），否则您将必须在业务规则中实现“变通方法”以弥补不合时宜的数据模型。

TL; DR：数据库取决于业务-由他们定义。除非您有一个处理该数据的流程（报告也是一个流程），否则您将不需要数据。首先实施该过程，然后您将找到所需的数据。首先对数据进行建模，当您首次对数据进行建模时，您也许可以计算出多少个错误的假设。

主题略有不同，但非常重要：我描述的工作流通常与非常重要的实践一起使用，例如“可能的最简单的事情”，测试驱动的开发以及着重于将架构与细节隔离开来。妨碍您（提示：数据库）。关于最后一个，这个演讲很好地总结了这个想法。

根本原因分析表明，此问题不是方法之一，而是缺乏规范。没有一个，您首先写什么并不重要-无论如何您将把它扔掉。

帮自己一个忙，并进行一些基本的系统分析-确定各个级别的一些用户，填写一份快速且肮脏的调查表，然后关闭机器，喝上咖啡和饼干/甜甜圈（或任何油脂的轮子），然后步行到他们的办公桌，问他们做些什么，以及他们需要知道/记录什么才能完成工作，即使看起来很明显-仍然要问。不必担心它们有多重要，如果他们太忙了，那么可以安排下一次回来或与他们在一起。

一旦有了，您就应该能够开始构建您认为可以给您最好的结果的任何东西，并等待其余的规范出现。

我的经验如下：

• 在我从事的大多数项目中，我们首先设计数据库。
• 通常，数据已经存在于电子表格，旧式数据库，纸张等中。这些数据将为您提供有关保存数据表的提示。
• 通常情况下，一个过程已经被使用，但是却是手动的，或者使用了几种不同的工具，这些工具不是自动化的，互操作的和/或不符合标准的。
• 一旦有了半成熟的数据库模型，就可以开始设计可读写该数据库的原型表单，窗口等。
• 随着您的继续，将需要进行一些更改以适应最初未考虑的情况。

还请记住：

• 它不再是一个单应用程序<->一个数据库的世界。也许您的应用程序将不得不从多个数据库中读取或写入数据，或者您的解决方案将包含使用同一数据库的多个应用程序。

结论：我建议您首先设计数据库。

我之所以说数据库优先，是因为我在大型项目方面有很多经验，如果您有许多并行工作的开发人员，那么您确实需要一个可靠的数据模型。

但是后来我对此进行了更多了解，我意识到在更成功的大型项目上我们真正要做的是“需求至上”。

一组明确规定的良好业务需求会导致一系列良好的功能需求。如果您有很好的功能需求，那么数据模型和模块规格就可以轻松投入使用。

由于这似乎很不确定/不确定，所以我首先要做前端GUI-听起来您需要从涉众那里获得响应，支持，时间和反馈，对吗？他们不在乎您出色的规范化表，外键约束和级联删除。但是很酷的GUI带有很多闪亮的颜色-嗯，这是一流的！

对于最初的后端“数据库”，请使用非常简单的方法，也许只是将键/值存储到文件中。我不熟悉MS Access，所以不知道“最轻量”的后端是什么。（一张铺有桌子的桌子？）不管是快速还是肮脏的，都要计划将其扔掉。

如果可以的话，请在GUI中使用有趣的外观，以明确它是原型。如果所有其他方法均失败，请使用索引卡。

现在，也许您的利益相关者是数据库专家-有时我就是这种情况！-在这种情况下，请进行一些数据库设计。

由于要求不明确，因此可以从一个非常初级的数据模型开始，其中包含您将知道需要的关键元素，也许只是基本表和PK。其余数据序列化为二进制或XML，然后将BLOB存储在数据库中。这应该允许人们在没有完全关系模型的情况下开发UI和业务层（中间层），但是您仍将具有保存和检索持久性以及根据需要进行简单键查找的持久性。

例如，也许您有一个人物，所以您有一个人物ID的PK。其余的属性未知，因此仅从带有PK Person ID的Person表开始，该表将存储Blob和所有person数据。

需求确定之后，请使用您的Blob并提取所有需要的表和列，并使模型具有关联性。然后，只需将持久性从BLOB更改为数据访问层中的关系即可。但是其他所有内容，业务规则UI等仍然可以使用。注意，这会增加项目时间，但可以完全灵活地根据需要添加和删除事物，而无需更改关系模型，直到事物变得更牢固为止

由于无法查询BLOB，因此搜索可能会延迟，因此随着模型的稳定，请开始将需要搜索的数据存储在关系列中。

基本上，您从表格模型开始，然后随着项目的进展移至关系模型。

或者，在开始任何工作之前确定需求，以便可以最初开发关系模型。

一般来说，我认为代码紧随数据之后，因为代码将操纵数据。

如果需求不明确，则可以创建一个解释需求的数据模型。最好的办法是写下一些要求，然后将其发送给您的雇主，然后他们可以提出一些建议。还是先创建一个GUI，这取决于雇主的类型，什么才最有效:)