如果您的存储需求很小，那么 SQL 数据库就显得多余了。当我年轻而愚蠢的时候，我使用了一个文本文件，并在需要访问它时对其进行了flock()。这无法扩展，但我仍然觉得非数据库解决方案在 Web 2.0 中已被完全忽略。
有人不使用 SQL 数据库进行存储吗？有哪些替代方案？
Steve Hanov
问问题
14834 次
16 回答
33
有很多选择。但是拥有 SQLite 可以为您提供 SQL 功能，并且无需大惊小怪的基于文件的存储，因此无需寻找这些替代方案。SQLite 足够轻，可以用于手机和 MP3 播放器，所以我不明白它怎么会被认为是矫枉过正。
因此，除非您的应用程序需要一些非常具体的东西，否则不要打扰。大多数替代品更难使用并且性能较差。
于 2009-03-24T13:05:55.593 回答
12
SQLite就是为此而发明的。
它只是一个包含完整 SQL 数据库的平面文件。您可以查询、更新、插入、删除，安装几乎没有开销，您只需要驱动程序（PHP 中的标准配置）
SQLite 是一个实现自包含、无服务器、零配置、事务性 SQL 数据库引擎的软件库。
有点奇怪，没有人提到这一点？
于 2009-03-24T14:02:02.917 回答
9
CouchDB ( http://couchdb.apache.org/index.html ) 是一个非 sql 数据库，现在似乎是一个流行的项目，还有 Google 的 bigtable 或 GT.M ( http://sourceforge. net/projects/fis-gtm）一直存在。
对象数据库也比比皆是。dbforobjects ( http://www.db4o.com/)、ZODB ( http://www.zope.org/Products/StandaloneZODB )，仅举几例。
对于某些用例，所有这些都比传统的 SQL 数据库更快、更简单，但没有一个能达到平面文件的简单性。
于 2009-03-24T13:17:57.560 回答
6
像google bigtable或hadoop这样的分布式哈希表是一种简单且可扩展的非 SQL 数据库，通常比 SQL 数据库更适合网站。SQL 非常适合复杂的关系数据，但大多数网站没有这个要求。大多数网站以几种形式存储和检索数据，并且不需要对数据运行复杂的操作。
看看其中一个解决方案，因为它们将提供您需要的所有并发访问，但不支持传统的数据规范化理念。它们可以被认为非常类似于一堆命名的文本文件。
于 2009-03-24T13:05:24.767 回答
4
这可能取决于您的网站的动态程度。我曾经使用过使用 RCS 签入和签出文本文件的 wiki 软件。对于像 StackOverflow 或 Wikipedia 那样获得尽可能多的更新的东西，我不会推荐该解决方案。关于数据库的事情是它们可以很好地扩展，并且数据库引擎编写者已经弄清楚了同时访问、负载平衡、复制等所有繁琐的小细节。
于 2009-03-24T13:04:54.957 回答
4
我想说这不取决于您存储的信息是少是多，而是取决于您请求存储数据的频率。数据库管理器在缓存查询方面非常出色，因此它们通常是性能更好的选择。但是，如果您不需要动态网页而只是加载静态数据 - 也许文本文件是更好的选择。数据以哪种格式存储（即 XML、JSON、key=pair）并不重要——I/O 操作对性能很重要。
当我开发 Web 应用程序时，我总是使用 RDBMS 作为主要数据持有者。如果 Web 应用程序不需要在每次请求时都提供动态数据，我只需应用一个缓存功能，将数据存储在一个缓存文件中，当没有新数据添加到主数据源（RDBMS）时，该缓存文件会被请求。
于 2009-03-24T13:08:45.587 回答
4
我不会根据我想存储多少数据来选择是否使用 SQL 数据库——我会根据我想存储什么样的数据以及如何使用它来选择。
维基百科将数据库定义为：数据库是存储在计算机系统中的记录或数据的结构化集合。而且我认为您的答案就在那里：如果您想存储诸如客户帐户、访问权限等记录，那么诸如 mySQL 或 SQLite 之类的数据库或其他任何不会过分的东西。它们为您提供了一种久经考验且值得信赖的机制来管理这些记录。
另一方面，如果您的网站存储和提供不变的基于文件的内容，例如 PDF、报告、mp3 等，那么只需将它们存储在磁盘上定义明确的目录布局中就足够了。我还会在此处包含 XML 文档：例如，如果您有一个生产部门以 XML 格式为网站创建文章，则无需将它们放在数据库中 - 将它们存储在磁盘上并使用 XSLT 来传递它们。
您是否选择 SQL 还取决于如何检索您希望存储的内容。SQL 显然适用于根据搜索条件检索许多记录，而目录树、XML 数据库、RDF 数据库等更有可能用于检索单个记录。
当尝试扩展高流量站点并将所有内容塞入 SQL DB 时，存储机制的选择非常重要，这将很快成为瓶颈。
于 2009-03-24T15:55:36.917 回答
2
这取决于您存储的内容。我的博客使用 Blosxom（用 Perl 编写，但可以为 PHP 做类似的事情），其中每个单独的条目都是一个单独的文本文件。第一行是纯文本（标题），其余的是不受限制的 HTML。遵循一些简单的规则，这些被呈现以形成一个简单但有效的博客框架。
它确实有缺点，但这也意味着每个帖子都是一个独立的文件，非常适合在本地计算机上更新然后发布到远程 Web 服务器。但是，这在高效查询方面是有限的，因此如果您想要与数据进行细粒度控制和基于 Web 的交互，这肯定不是一个好的选择。
于 2009-03-24T15:39:10.593 回答
1
检查CouchDB。
于 2009-03-24T13:15:10.110 回答
1
我在 .NET 项目中使用 LINQ to XML 作为数据源。这是一个小型解决方案，并使用缓存来缓解性能问题。对于只需要将数据保存在公共位置而不增加服务器要求的快速站点，我会再次这样做。
于 2009-03-24T13:18:25.580 回答
0
取决于您存储的内容以及您需要如何访问它。通常sql提供了很好的报告和手动管理能力。几乎所有东西都需要某种方式来管理存储的内容并对其进行报告。
于 2009-03-24T14:42:25.550 回答
0
在 Perl 中，我使用 DBM 或 Storable 来完成此类任务。DBM 将在变量更新时自动更新。
于 2009-04-26T23:45:18.620 回答
0
一个简单的答案是您可以使用任何数据存储格式，从标准定义到数据库（通常涉及协议），甚至是定制的文件格式。
您在 IT 领域做出的每一个选择都需要权衡取舍，当然网站也不例外。在 2000 年初，基于文件的论坛系统很流行，因为它允许任何技术能力有限的人编辑页面和帖子。完全静态的站点很快变得无法管理，并且内容不会从站点用户界面的升级中受益；但是，如果网站编码正确，则可以简单地将其移动到子目录，或翻录到新设计中。CMS 和动态系统带来了它们自己的一系列问题，即它们之间尚不存在广泛采用的数据存储标准；他们经常依赖第三方插件来提供设计风格之间的功能（尽管他们的文档提倡功能和形式的分离）。
在 2016 年，不使用标准存储机制的情况非常罕见，例如 *SQL RDBMS；尽管 Jekyll 等静态站点生成器（为许多 GitHub 页面提供支持）；像 October CMS 这样的独立玩家仍然提供基于静态文件的存储。
我个人的偏好是使用启用 *SQL 的 RDBMS，它为我提供了至少在供应商级别标准化的语法、熟悉且强大的语法，但与很多人不同的是，我认为这不是唯一的方法，并且在大多数情况下会提倡使用站点生成器将不必是动态的部分保存到静态存储中，因为这是在网络上生活的最便宜的方式。
TLDR；由你决定，支持 SQL 和 RDBMS 很受欢迎。
于 2016-03-28T23:36:00.590 回答
0
好吧，这是来自 OP 的一个开放式问题，有两个问题......围绕 SQL 替代方案和非 SQL。
一般来说，在“为什么 SQL 好”类别中……它是一个成熟且强大的标准，可提供引用完整性。Java JDBC 完全支持它，就像 TOAD 之类的工具一样，还有许多 SQL 实现，例如前面提到的 SQL-Lite。
现在特定于“用于网站”并不能特别说明任何事情。网站是否需要参照完整性？也许。如果网站的业务性质主要是非结构化内容，那么可以考虑任何类型的持久存储，从 AWS DynamoDB 等所谓的“非 SQL”数据库到 Mongo（虽然不是粉丝）。
对于管理 SQL 存储的复杂性 - 一个建议与曾经创建的每个持久性存储的列表相比……是 AWS Aurora（RDS 服务的一部分）。它是多区域主动-主动且完全兼容 MySQL。基于 JDBC/ODBC 的驱动程序框架可以开箱即用，并且有效地提供“零管理”。
于 2020-04-01T20:02:28.263 回答
-4
如果我是你，我会检查 XML。请参阅左侧的w3schools XML 教程部分。不使用 SQL 数据库的大量可能性。
于 2009-03-24T12:59:34.673 回答