如果您的存储需求很小，那么使用SQL数据库就有点大材小用了。当我年轻无知时，我使用文本文件，并在需要访问它时使用flock()函数。这种方法不能扩展，但我仍然认为非数据库解决方案在Web 2.0中完全被忽略了。
是否有人不使用SQL数据库进行存储？有哪些替代方案？
16个回答
33
有很多替代方案，但是拥有SQLite可以让你使用SQL功能而不需要繁琐的基于文件的存储，所以没有必要寻找这些替代方案。SQLite足够轻便，可以在手机和MP3播放器中使用，因此我不认为它会被视为过度。
因此，除非您的应用程序需要非常具体的功能，否则不必费心。大多数替代方案都更难使用且性能较差。
- vartec
12
SQLite 是为此而发明的。
它只是一个包含完整 SQL 数据库的平面文件。您可以查询、更新、插入、删除，安装几乎没有任何开销，您所需要的仅是驱动程序（PHP 中提供标准驱动程序）。
SQLite 是一个软件库，实现了自包含、无服务器、零配置、事务性 SQL 数据库引擎。
有点奇怪，竟然还没有人提到这个？
- SchizoDuckie
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 数据库更快、更简单，但没有哪一个能够达到平面文件的简单性。
- vezult
2
ZODB通常与RDBMS一起用作存储层，所以我不确定这是否是一个好的例子。它更像是ORM。 - vartec
一个ORM与关系型后端的概念紧密耦合，而ZODB没有。它被设计为具有可插拔存储的对象数据库。我站在我的选择旁边。;o) - vezult
6
一个分布式哈希表，比如Google Bigtable或Hadoop，是一个简单而可扩展的非SQL数据库，通常比SQL数据库更适合于网站。SQL适用于复杂的关系型数据，但大多数网站不需要这种要求。大多数网站以几种形式存储和检索数据，不需要对数据进行复杂的操作。
看一下其中一个解决方案，它们将提供所需的所有并发访问，但不遵循传统的数据规范化思想。它们可以被看作是一堆命名的文本文件。
看一下其中一个解决方案，它们将提供所需的所有并发访问，但不遵循传统的数据规范化思想。它们可以被看作是一堆命名的文本文件。
- JayArr
1
我必须说我喜欢http://morris.github.io/microdb/。它看起来比sqlite或bigtable更容易，因为您不需要定义任何对象模型。 - Michiel van der Blonk
4
这可能取决于你的网站有多动态。我曾经使用过一种维基软件，它使用RCS来检入和检出文本文件。对于像StackOverflow或Wikipedia这样频繁更新的内容，我不建议使用这种解决方案。数据库的好处是它们可以很好地扩展，并且数据库引擎编写者已经解决了所有同时访问、负载平衡、复制等琐碎的细节。
- Paul Tomblin
4
我认为，这并不取决于您存储的信息量大小，而是取决于您请求已存储数据的频率。数据库管理器在缓存查询方面非常出色，因此通常在性能方面更好。然而，如果您不需要动态网页，只需加载静态数据-也许文本文件是更好的选择。存储数据的格式（即XML、JSON、键值对）并不重要-输入/输出操作是性能瓶颈。
当我开发Web应用程序时，我总是使用关系型数据库作为主要数据持有者。如果Web应用程序不需要在每个请求中提供动态数据，我只需应用缓存功能，将数据存储在缓存文件中，当主数据源（RDBMS）没有添加新数据时请求该文件。
当我开发Web应用程序时，我总是使用关系型数据库作为主要数据持有者。如果Web应用程序不需要在每个请求中提供动态数据，我只需应用缓存功能，将数据存储在缓存文件中，当主数据源（RDBMS）没有添加新数据时请求该文件。
- Björn
4
我不会根据我想存储的数据量来选择是否使用SQL数据库，而是根据我想要存储的数据种类以及如何使用它来进行选择。
维基百科定义数据库为：“数据库是一个结构化的记录或数据集合，存储在计算机系统中”。我认为你的答案就在这里：如果你想存储像客户帐户、访问权限等记录，那么像mySQL或SQLite等数据库并不过度。它们为您提供了一种经过验证和可靠的机制来管理这些记录。
另一方面，如果您的网站存储和提供不变的基于文件的内容，例如PDF、报告、mp3等，则只需将它们存储在磁盘上的明确定义的目录布局中就足够了。我还会在这里包括XML文档：如果您有一个生产部门，他们以XML格式创建网站文章，则无需将它们放入数据库中-将它们存储在磁盘上并使用XSLT来传递它们。
您选择使用SQL与否也取决于您希望检索的内容如何。 SQL显然非常适用于基于搜索条件检索多个记录，而目录树、XML数据库、RDF数据库等更可能用于检索单个记录。
在尝试扩展高流量网站时，存储机制的选择非常重要，将所有内容都塞入SQL数据库中很快就会成为瓶颈。
维基百科定义数据库为：“数据库是一个结构化的记录或数据集合，存储在计算机系统中”。我认为你的答案就在这里：如果你想存储像客户帐户、访问权限等记录，那么像mySQL或SQLite等数据库并不过度。它们为您提供了一种经过验证和可靠的机制来管理这些记录。
另一方面，如果您的网站存储和提供不变的基于文件的内容，例如PDF、报告、mp3等，则只需将它们存储在磁盘上的明确定义的目录布局中就足够了。我还会在这里包括XML文档：如果您有一个生产部门，他们以XML格式创建网站文章，则无需将它们放入数据库中-将它们存储在磁盘上并使用XSLT来传递它们。
您选择使用SQL与否也取决于您希望检索的内容如何。 SQL显然非常适用于基于搜索条件检索多个记录，而目录树、XML数据库、RDF数据库等更可能用于检索单个记录。
在尝试扩展高流量网站时，存储机制的选择非常重要，将所有内容都塞入SQL数据库中很快就会成为瓶颈。
- Steve Claridge
2
这取决于您要存储什么。我的博客使用Blosxom（用Perl编写，但可以为PHP做类似的事情），其中每个单独的条目都是一个单独的文本文件。第一行是纯文本（标题），其余部分是不受限制的HTML。遵循一些简单的规则，这些内容会被呈现成一个简单而有效的博客框架。
它确实有缺点，但也意味着每篇文章都是一个独立的文件，非常适合在本地机器上更新，然后发布到远程Web服务器。但是，当涉及到高效查询时，这种方式存在局限性，因此如果您想对数据进行细粒度控制和基于Web的交互，则不是一个好选择。
它确实有缺点，但也意味着每篇文章都是一个独立的文件，非常适合在本地机器上更新，然后发布到远程Web服务器。但是，当涉及到高效查询时，这种方式存在局限性，因此如果您想对数据进行细粒度控制和基于Web的交互，则不是一个好选择。
- basswulf
1
我在一个.NET项目中使用了LINQ to XML作为数据源。这是一个小型解决方案，使用缓存来缓解性能问题。如果只需要将数据保留在一个公共位置而不增加服务器要求的快速站点，我会再次使用它。
- ccook
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接