我和一个朋友正在讨论他是否应该使用 MySQL 或平面文件数据库作为他网站的后端。我告诉他选择 MySQL，因为它结构清晰，记录良好，并且是一致的。另一方面，他说他宁愿追求速度。读取文件比连接 MySQL 快得多，这让我怀疑他是否正确。例如，为什么不为每个表创建一个文件夹，如下所示：users/ groups/ posts/，在文件夹中有由 ID（1，2，3）命名的文件，然后为数据使用如下格式：username: John\npassword: e2fc714c4727ee9395f324cd2e7f331f\nemail: example@example.com？
换句话说，MySQL 相对于平面文件有哪些优势？
换句话说，MySQL 相对于平面文件有哪些优势？
MySQL提供索引和连接（用于执行性能）、事务（用于数据完整性）和SQL（用于开发性能）。
如果您的项目只涉及一个3自给自足的文本文件，则不需要MySQL.
读取文件比连接 MySQL 快得多，这让我怀疑他是否正确。
鹅卵石。像 mySQL 这样的数据库也将其数据存储在文件中，但具有大量优化功能，最明显的是它的索引功能，与读取（或写入）大型平面文件相比，可以大幅提高性能。
在某些非常有限的情况下，平面文件可能更快，但数据库引擎利用了几代开发人员的经验，致力于使数据访问更快、更可靠。例如，当您的脚本的两个实例尝试将数据写入数据库时，只需考虑竞争条件和锁定。
如果使用的数据量超过 CSV 文件中的几行 - 或者碰巧在 Wiki 页面等文件中不容易管理 - 使用数据库。它增加了一层复杂性，但为您省去了很多麻烦。
只需考虑快速SELECT * FROM posts WHERE MONTH(post_date) = "2010-03-10"对平面文件进行操作，以及从头开始编写以实现此目的所必需的。
请问什么是“平面文件数据库”？平面文件是平面文件 - 像这样命名它。说它是一个平面文件数据库会让您认为它神奇地具有数据库的一些功能 - 每个定义的平面文件都没有。
MySQL 相对于平面文件的优势是什么？
在这里跳过 MySQL——你问的主要问题是“为什么要使用数据库”。
我建议您查看性能（搜索操作 - 索引的存在是有原因的）并查找术语“ACID 条件”以对数据库实际执行的操作有一个更模糊的概念。
平面文件不能给你任何保证，几十年的开发人员已经一次又一次地证明了他们遇到的所有问题。
还有安全问题。如果您没有正确保护平面文件，它们可能更容易暴露。特别是如果您要存储用户信息，则在平面文件周围没有进入障碍。
假设您的网站或应用程序垂直增长，平面文件也不会缩放，因为平面文件越大，阅读时间就越长。
最后，在已经很容易使用数据库的情况下使用平面文件非常简单。因为每个人都使用数据库，这并不是以“正确的方式”做事，所以我会反驳：为什么在 MySQL 上使用平面文件？在了解或同意您使用平面文件的决定之后，是否会有其他人来维护您的应用程序？
我们需要更多的上下文。
如果您的朋友正在阅读完整的页面（数据库中存储的广告“blob”），那么是的，使用 MySql 并没有多大帮助。如果他有细粒度的数据（包括，我不知道，博客文章、新闻站点、带有元数据的图像、订单详细信息），那么除非该站点非常简单且非常静态，否则基于文件的方法很快就会变得过于有限。
您提出的解决方案有两个很大的缺点：
使用文件夹/文件名与在每个表上只有一个索引（在本例中为文件名）相同，因此搜索任何其他条件都需要很长时间。更不用说在单个目录中有大量文件会开始对操作系统征税这一事实。
最重要的是，即使您使用散列密码作为 URL 的一部分，security-by-filename 也会带来一些安全风险。
我过去做过一些基于文件系统的中型应用程序（由于管理不善的要求，我们不能使用数据库），这很有趣，但是当你浏览数百个文件时，确实非常有限。即使数量很少，您也必须从一开始就开始使用技巧，以保持工作正常。
举个例子：假设您有 1,000,000 名客户，有地址信息，您需要搜索和设置居住在纽约的客户。如果您将每个客户存储在单独的文件中，那么您将需要读取所有 1,000,000 个文件并查看客户是否属于该州。如果您将所有记录存储在一个大文件中 - 您需要读取整个文件并迭代以查找来自纽约的所有客户。
在这两种情况下，你都松了。
对于像 MySql 这样的 RDBMS - 您将使用所谓的“设置”操作或 SELECT 语句，并添加索引，引擎读取的数据可能只比查找来自纽约的所有客户所需的数据多 10/20%。
希望这可以帮助
此外，如果不将所有用户信息存储在Posts/文件夹中，您如何获得 John Doe 撰写的所有帖子（例如）？在 SQL 中，它只是一个连接的 select 语句。对于平面文件，您要么必须将信息存储在实际的发布文件中，要么编写代码自行执行连接和搜索操作。
数据冗余和缺乏原子性是平面文件数据库中的大问题，它以指数方式表现出需要保存的数据越多，并在查询和其他问题（如更新/删除/插入异常）中引入延迟。
具有规范化的关系数据模型有助于消除这些问题，通过确保原子性和每个记录是唯一可识别的（第一范式），表中的每个字段在功能上依赖于主键（第二范式）并且非关键字段不与表中的其他字段共享传递依赖项（第三范式）。
关系数据模型绝不是唯一的方法，甚至可能不是最好的方法，但它确实试图解决平面文件中固有的查询延迟和异常问题。
mysql与flatfile相比有一些优势，文件结构不好查询，但是文件中的CRUD比mysql快，可以使用mongo db等no-sql数据库，结构更好，速度更快，sql和sql还是有区别的no-sql 数据库，但我认为使用 no-sql db 而不是 flatfile 更好，还要注意如果你在 bigdata 上工作 no-sql db 肯定比 sql 好..