确定何时使用数据库的最佳方法是什么？

13

我开始使用PHP和MySQL进行网络开发的编程生涯。我已经习惯了使用db来存储大多数动态数据以及一些设置/参数数据。有时会有很多数据，而其他时候表中的条目会很少。在我看来，这似乎很自然，据我所知，这或多或少是Web开发中可接受的方法。（如果我错了，请纠正我...）

我现在正在研究桌面应用程序，我的自然倾向是再次利用数据库来存储大量信息，这些信息将通过使用该应用程序而生成。 ~~但是，据我所知，我看不到应用程序（我使用的）经常使用db。~~ [编辑：自那以来，有人指出这是一个错误的假设，因为许多应用程序确实使用嵌入程序本身的轻量级数据库。] 这是什么原因？在什么时候使用数据库是合适的？关于这件事有什么标准吗？还有什么原因不使用数据库来开发桌面应用程序呢？

database desktop-application

— 肯尼斯
source

2

“但是，据我所知，我看不到（使用的）应用程序经常使用db”？基于什么？如果他们使用SQLite，您怎么知道他们是否正在使用数据库？

— S.Lott

这就是为什么据我所知我只能说我可能错了的原因。我认为可能有些应用程序使用嵌入式数据库的...应用程序使用数据库是否很常见？

— 肯尼思

@Kenneth：请向Google购买嵌入式数据库，例如SQLite。有许多。它们被广泛使用。AFAIK，Apple的iOS将其用于所有持久性。请谷歌。

— S.Lott

2

我谷歌很多。有时候，虽然没有什么能取代经验丰富的意见，但您总无法找到Google。

— 肯尼思

1

我认为这些评论足以纠正错误的假设。对于错误，我深表歉意。我觉得自己经常使用Google询问和提问的健康组合。有时，没有什么可以替代后面的恕我直言。现在，我的谷歌搜索将得到更好的指导和更高的效率。

— 肯尼思

4

如果您的应用程序是面向文档的，则将内容存储在文档文件中

如果您的应用程序处理的是更多结构化的数据，而对于单个文档（例如XML文档）而言则过多，请使用数据库

— 史蒂文·洛
source

7

传统上，数据库系统被视为相对繁重的服务-您不一定要在其中的每台客户端计算机上安装数据库系统。实际上，我曾经遇到过这样的情况（需要保存大量数据的桌面GUI应用程序开发），真正的DB系统本来是“理想的”解决方案-但是由于那时候唯一的可用数据库相对较重，我们改用平面数据文件。

尽管最近有一些轻量级的数据库，但这仍然是反对客户端数据库的有效论据。想象一下一些简单的小型桌面应用程序（例如，简单的桌面玩具或游戏）必须存储几十个设置和参数。似乎让一个人安装MySQL只是为了运行您的应用程序是一种超越方式。

对于Web开发而言，服务器自然是后端，拥有数据库是其中的关键。例如。用户不必担心在最后安装数据库。

— 鲍比表
source

因此，您建议不要将db用于独立应用程序，除非确实需要大量数据？

— 肯尼思

您对使用轻量级数据库的看法与全尺寸数据库相同？

— 肯尼思

1

@肯尼思：我会说“取决于”。如果应用程序需要大量的表格数据，而这些数据确实需要包含在适当的数据库中，则该参数可能足够强大，可以为应用程序提供轻量级的数据库。但是，如果只是配置/设置类型的数据，那可能就太过分了。

— Bobby Tables'Mar

5

桌面应用程序在运行时会保持状态。Web开发通常不这样做。因此，尽管您可能需要在两次页面加载之间将用户设置存储在数据库中，但在桌面应用程序中，您只需将它们保存在内存中即可。这大大减少了对此类持久性存储的需求。当您希望在使用之间存储首选项时，可以将它们全部保存到一个文件中，也可以将它们放置在Windows注册表等位置。

话虽这么说，数据库系统在台式机应用程序中已大量使用。早在网络出现之前，桌面应用程序已连接到DBMS。主要用于非基于文档的应用程序。尽管这些天来，随着轻量级引擎的可用性越来越好，您正在逐渐模糊界限。以前，我在一些应用程序中使用SQLite db 作为文档。

— 大师B
source

+1如果您没有复杂的持久性问题，例如多用户，多位置，同时阻止更新，则传统数据库可能会过大。如果所讨论的数据是相当静态的（它可能会增长或添加，但不会演变或更新），并且扩展/竞争并不频繁或不正常（副作用/用户等待锁定释放的经验）考虑到性能和复杂性之间的折衷并非不可接受），您可能不需要数据库。

— JustinC 2011年

4

您可能需要研究的一件事是不需要实际运行的数据库服务的轻量级数据库。例如，在Microsoft方面，有一个免费的SQL Server Compact，它只需要一个数据库文件和一些DLL添加到您的应用程序，并且从开发人员的角度来看，其行为与“真实的” SQL Server大致相同。

我很肯定其他平台也有类似的选择。

— 卡森63000
source

1

Java方面的一个非常相似的示例是Derby。我认为也有其他人。

— jprete 2011年

1

听起来这可能是一个理想的解决方案...我真的很喜欢利用db的功能！大声笑

— 肯尼斯（Kenneth）

使用轻量级数据库有不利之处吗？

— 肯尼思

@Kenneth：它们使您的安装更大，并且可以增加代码库。但这比在客户端上安装整个数据库服务器要少得多，通常仅在应用程序分发且需要更强大的数据库时才这样做。在伯克利DB是最常用的。

— 2011年

另一个选择是SQLite，它在RAM和磁盘空间上都轻得多，并且没有任何限制。难怪所有非MS智能手机和Web浏览器都使用它。

— 哈维尔

2

在Web应用程序上，将任何持久状态存储在集中式存储中非常重要。由于Web应用程序通常是第一个瓶颈，因此能够分发它而不必怀疑哪个副本具有数据（“无共享”原则）非常重要。memcached出于相同的原因，不仅有数据库，而且还有队列系统。

桌面应用程序没有相同的可扩展性目标。通常，大多数数据本地存储在每个工作站上。在大多数情况下，数据共享是一个不同的问题。这消除了使用数据库的一个重要原因。

GUI应用程序还可以具有复杂的文档，这些文档可以作为内存中的复杂对象网络处理。将结构规范化为关系数据库模式会增加问题的复杂性，有时将整个事情序列化为单个字节流会更容易。许多OOP框架为此提供了一些功能。

不过，在许多情况下，使用主应用程序外部的工具使存储的文档可读性仍然是一个很大的优势，因此，无论是使用人类可读的格式（XML，JSON，YAML等），还是将几个更简单的片段合并在一起的zipfile都越来越多，并且比较普遍;普遍上。

同样，使用可嵌入的数据库库（BDB，Tokyo Cabinet，SQLite，MS-SQL * server Compact等）是另一种不错的方法。

— 哈维尔
source

1

数据库可以是矫枉过正，但他们通常不具备如此。非常简单的程序只是不需要它们。如果您的文档可以在很短的时间内加载到内存中，并且可以毫无问题地停留在内存中，那么对于许多程序，您实际上并不需要一个。

例如考虑：

#include "superheader.h"

int main()
{
    int row=2, column=2;
    DatabaseType db;
    db.ConnectTo("programDB", "user", "pass");
    db.setTable("messages");
    string hello_world=db.fetch(row, column);
    cout<<hello_world;
    return 0;
}

太简单了，但是显然这太过分了。对于“ Hello World”拥有如此级别的数据管理没有任何实质意义。

通常，如果您有很多数据集，尤其是如果它们具有独特的区别，那么我经常使用的规则是使用数据库；如果数据量非常大，则使用数据库。通常，数据库与一些开销相关联，但是有许多实际上并没有太多开销。例如，小型，轻量级的内存数据库有时对处理繁重，日程安排或数据有大量动态更改的小型项目很有用。

有不同的编码样式，很多时候数据库没有错，但是我们大多数人不会对基本任务走那么远。还有其他时候，正确的数据库可以提供性能优势。尝试特别了解数据将在何处，将存在多长时间以及将在其生命周期内对其进行更改的差异。

— 加雷特·克拉伯恩
source

1

使用数据库始终是正确的选择，而对于SQLite实现来说，实际上几乎所有不使用一种语言的设计决策都是不正确的。不使用它的唯一原因是，如果您正在执行嵌入式编程或某种其他类型的非应用程序形式的编程。与使用命令性语法遍历平面文件或内存中的其他对象相比，使用诸如SQL之类的声明性语言查询数据和设置要自然得多。此外，它将数据操作与其他应用程序代码完全分开，从长远来看，这使代码更具模块化和可维护性。

— davidk01
source