什么时候值得使用数据库？

我有一个关于数据库的问题，在什么地方值得深入研究。我主要是一名embedded式工程师，但是我正在编写一个使用Qt与我们的控制器进行交互的应用程序。

我们有一个奇怪的地方，就是我们有足够的数据可以实现一个数据库（大约700多个项目和不断增长）来pipe理所有的事情，但我不知道现在是否值得现在处理。使用从excel生成的文件和parsing的文件实现GUI是没有问题的，但是即使使用VBA脚本，也很难跟踪。我一直在玩转换我们的数据到Microsoft Access的应用程序方面更可pipe理，似乎运作良好。如果解决了这个问题，我只需要使用SQL数据库和使用Qt库来访问和修改它。

我没有太多的经验来pipe理这个级别的数据，我很好奇什么是解决这个问题的最好方法。那么在这种情况下使用数据库有什么好处呢？我意识到这其中的大部分都可以是特定于应用程序的，但是关于如何跨越embedded式/应用程序编程线的一些总体思路和build议将会有所帮助。

这不是关于将数据库放入embedded式项目。这也不是一个通常使用大型数据库的业务types应用程序。我正在为桌面上的单个用户devise一个GUI，以便与微控制器进行交互以进行监视和configuration。

我决定去与SQLite。你可以用一些非常有意思的事情来做这些事情，但是在第一次启动这个项目时，我并没有真正考虑过这个选项

数据库值得：

您的应用程序演变为某种forms的数据驱动执行。
您花费在devise和开发外部数据存储结构上的时间。
在应用程序或组织（包括个人）之间共享数据
数据不再简短。
数据复制

数据驱动执行的演变
当数据改变但执行不是时，这是数据驱动程序的标志，或者程序的一部分是数据驱动的。一组configuration选项是数据驱动函数的标志，但整个应用程序可能不是数据驱动的。无论如何，一个数据库可以帮助pipe理数据。（数据库库或应用程序不必像甲骨文那样庞大，但可以精简而且像SQLite一样）。

外部数据结构的devise与开发
将问题发布到堆栈有关序列化或将树和列表转换为使用文件的溢出很好地表明您的程序已经逐渐使用数据库。另外，如果您花费任何时间devisealgorithm来将数据存储在文件中，或者将数据devise为文件是研究数据库使用情况的好时机。

共享数据
无论您的应用程序是与另一个应用程序，另一个组织或另一个人共享数据，数据库都可以提供帮助通过使用数据库，数据一致性更容易实现。问题调查中的一个重大问题是团队没有使用相同的数据。客户可以使用一组数据; validation团队另一个和发展使用不同的数据集。数据库使数据更容易版本化，并允许实体使用相同的数据。

复杂的数据
程序开始使用硬编码数据的小表。这演变成使用具有地图，树和列表的dynamic数据。有时数据从简单的两列扩展到8或更多。数据库理论和数据库可以减轻组织数据的复杂性。让数据库担心pipe理数据并释放应用程序和开发时间。毕竟，如何pipe理数据并不像数据的质量和可访问性那么重要。

数据复制
通常情况下，当数据增长时，重复数据的吸引力将不断增加。数据库和数据库理论可以最大限度地减less数据的重复。数据库可以configuration为警告重复。

转向使用数据库有许多因素需要考虑。其中一些包括但不限于：数据复杂性，数据重复（包括部分数据），项目截止date，开发成本和许可问题。如果您的程序可以更有效地运行数据库，那就这样做。数据库也可以节省开发时间（和金钱）。与pipe理数据相比，您和您的应用程序还可以执行其他任务。将数据pipe理留给专家。

你所描述的不像一个典型的商业应用程序，许多已经发布在这里的答案都假设这是你正在讨论的应用程序，所以让我提供一个不同的视angular。

无论您是否使用700个项目的数据库，都将极大地依赖于数据的性质。

我会这么说，大约90％的时间在这个规模上，你将受益于像SQLite这样的轻量级数据库，只要：

数据的潜在增长可能远远大于你所描述的，
数据可以由多个用户共享，
您可能需要对数据运行查询（我认为您现在不这么做），以及
数据可以很容易地以表格forms描述。

另外10％的时间，你的数据将是高度结构化的，分层的，基于对象的，并不能整齐地放入数据库或Excel表格的表格模型中。如果是这种情况，请考虑使用XML文件。

我知道开发人员本能地喜欢把数据库放在这样的问题上，但是如果您正在使用Excel数据来devise用户界面（或显示configuration设置），而不是显示客户logging，则XML可能更适合。 XML比Excel或数据库表更具有performance力，并且可以使用简单的文本编辑器轻松进行操作。

用于C ++的XMLparsing器和数据绑定器很容易find 。

我build议你在你的应用程序中引入一个数据库，你的应用程序将获得灵活性，将来会更容易维护和改进新function。
我会开始一个像Sqlite的基于轻量级文件的数据库。
有了精心devise的分贝，你将有：

减less数据冗余
更高的数据完整性
改进的数据安全性

最后但并非最不重要，使用数据库将从Excel导入/更新/导出地狱拯救你！

我看到了数据库很好满足的一些要求：

1）。特别查询。 find符合条件Y的所有{X}

2）。具有可从正常化中受益的结构的数据 – 将通用值分解成单独的“表”。您可以节省空间并通过这种方式减less不一致的可能性。一旦你完成了这些，那么这些特别的查询就开始变得非常有用了。

3）。庞大的数据量。专业数据库非常善于利用资源，聪明的查询optmisations和分页策略。试图自己写这些东西是一个真正的挑战。

你显然不需要最后一个，但另外两个，也许适用于你。

使用数据库的原因：

并发写道。在数据库中实现并发很容易
轻松查询。 SQL查询往往比程序代码更加简洁，以便search数据。更新，INSERT INTOs也可以用很less的代码做很多东西
诚信。约束非常容易定义，并且在不编写代码的情况下执行。如果你有一个非空的约束，你可以放心，这个值不会为空，不需要在任何地方写检查。如果你有一个外键约束，你将不会有“悬挂引用”。
在大型数据集上的性能。索引添加到SQL数据库非常简单

不使用数据库的原因：

它往往是一个额外的依赖（虽然有非常轻量级的数据库，例如我喜欢H2）
数据不太适合关系模式。基本上是关键/价值地图的东西。 XML（尽pipe数据库通常支持XPath等）。
有时文件更方便。他们可以被区分，合并，用纯文本编辑器编辑等。有时电子表格可以更实用（你不必build立一个编辑器 – 你可以使用电子表格程序）
你的数据已经在别的地方了

当你有大量的数据，你不知道他们将来如何被利用。

例如，您可能希望在需要注册统计信息的embedded式应用程序中添加SQLite数据库，但您不知道如何使用SQLite数据库。稍后，您将完整的数据库发送到在中央服务器上运行的更大的数据库，并且可以使用请求轻松利用这些数据。

事实上，如果您的应用程序的目的是“收集数据”，那么拥有一个数据库是必须的。

不要忘记，根据您的要求，相应的数据库可能会有很大的不同（如果您的要求足够简单，不要忘记可以使用文本文件作为数据库 – 例如，configuration文件只是特定的种类的数据库）。这些参数可能是：

logging数
数据项的大小
数据库是否需要与其他设备共享？同时？
各种数据之间的关系有多复杂
是只读的数据库（例如在编译时创build，没有改变）？
数据库是否需要由多个实体同时更新？
你需要支持复杂的查询吗？

对于包含700个条目的数据库，从文本文件加载的内存中已sorting的数组可能是合适的。但是我也可以看到需要embedded式SQL数据库，或者让控制器通过networking连接从数据库请求数据，这取决于各种需求（和资源限制）。

没有一个数据库是值得的具体点。相反，我通常会问以下问题：

应用程序使用/创build的数据量是否增长？
这个数据增长的上限是未知的（还是不清楚）？
应用程序是否需要汇总或过滤这些数据？
未来可能会使用那些可能不明显的数据吗？
数据检索和/或存储的性能是否重要？
共享数据的应用程序是否有多个用户（或可能有多个用户）？

如果我对大多数这些问题回答“是”，我几乎总是select一个数据库（而不是其他选项，如XML / ini / CSV / Excel /文本文件或文件系统）。

此外，如果应用程序将有许多用户可以同时访问数据，我会倾向于一个完整的数据库服务器（MySQL，SQl服务器，Oracle等）。

但通常在单用户（或小并发）的情况下，像SQLite这样的本地数据库不能被打败，以实现可移植性和易部署性。

要添加否定性：由于非确定性延迟，不适合实时处理。但是，例如在启动期间，查找和设置操作参数将是相当充足的。我不会把数据库访问放在关键的时间path上。

如果在一个或两个表中有几千行来处理单个用户应用程序（对于embedded点），则不需要数据库。

如果是针对多个用户（并发访问，locking）或者需要事务的初始化应该考虑一个数据库。在规范化的表格中处理复杂的数据结构，维护完整性或大量的数据将是您应该使用数据库的另一个迹象。

这听起来像你的应用程序正在桌面计算机上运行，只是与embedded式设备进行通信。

因为使用数据库更可行。在embedded式平台上使用一个更复杂的问题。

在桌面方面，当需要连续存储新信息以及需要以关系方式提取信息时，我使用数据库。我不使用数据库的是存储静态信息，信息我读一次在加载和多数民众赞成它。当应用程序有很多用户，并且需要以每个用户为基础存储这些信息时，这是个例外。

听起来像是从你的embedded式设备收集信息，以某种方式存储它，然后稍后使用它通过GUI显示。

这是使用数据库的一个很好的例子，特别是如果您可以构build系统，以便有一个数据收集守护程序来pipe理与embedded式设备的连续通信。这个应用程序可以将数据写入数据库。当GUI启动时，它可以提取数据以供显示。

如果您需要显示不同的视图，例如“显示两个date之间的所有条目”，使用数据库还将减轻您的GUI开发。使用数据库，您只需要询问正确的值以显示正确的SQL查询，而GUI将显示返回的内容，从而允许您从GUI中分离出大部分“业务逻辑”代码。

我们也面临着类似的情况。我们有来自不同testing设置的数据集，目前正在转储到Excel表格中，使用Perl或VBA进行处理。

我们发现这个方法有很多问题：

一世。使用Excel表pipe理数据非常麻烦。一段时间后，你有很多的Excel表，并没有简单的方法来从中检索所需的数据。

II。人们开始发送Excel表格来回复评论和通过电子邮件审查。电子邮件成为pipe理与数据相关的评论的主要模式。这些评论在晚些时候丢失了，没有办法找回来。

III。创build文件的多个副本，并且一个副本中的更改不会反映在另一个副本中 – 没有版本控制。

这也是出于同样的原因，我们决定转向基于数据库的解决scheme，目前正在开展工作。让我总结一下我们正在做的事情：

一世。数据库位于所有testing设置中的PC可访问的中央服务器中。

II。所有数据一旦生成，就会进入临时位置（文件中的本地硬盘）。从文件中，通过在后台运行的进程将文件压入数据库（即使存在networking问题，数据也会存在于本地文件系统中）。

III。我们有一个基于Web的应用程序，允许用户以他们想要的格式login和访问数据。门户允许他们添加评论，生成不同types的报告，经过审核后与其他用户共享等等。它还能够将数据导出到Excel表格中，以防万一需要随身携带。