代码之家  ›  专栏  ›  技术社区  ›  John M.

为什么在平面文件上使用MySQL?

  •  7
  • John M.  · 技术社区  · 16 年前

    我和一个朋友在争论他应该使用MySQL还是在他的网站后端使用一个平面文件数据库。我告诉他使用MySQL,因为它是结构化的,保存得很好,并且是一致的。另一方面,他说他宁愿追求速度。读取文件比连接到MySQL快得多,这让我怀疑他是否是对的。例如,为什么不为每个表创建一个文件夹,比如: users/ groups/ posts/ ,文件夹中的文件按ID命名( 1 , 2 , 3 )然后对数据使用这样的格式: username: John\npassword: e2fc714c4727ee9395f324cd2e7f331f\nemail: example@example.com ?

    换句话说,MySQL比Flatfile有什么优势?

    9 回复  |  直到 10 年前
        1
  •  11
  •   Quassnoi    16 年前

    换句话说,MySQL比Flatfile有什么优势?

    MySQL 提供索引和联接(用于执行性能)、事务(用于数据完整性)和 SQL (用于开发性能)。

    你的项目只涉及 3 -行自给自足的文本文件,您不需要 MySQL .

        2
  •  10
  •   Pekka    16 年前

    读取文件比连接到MySQL快得多,这让我怀疑他是否是对的。

    Hobcobbles。像mysql这样的数据库也将其数据存储在文件中,但是它有大量的优化功能,最明显的是它的索引功能,允许 巨大的 与读取(或写入)大型平面文件相比,性能有所提高。

    在某些非常有限的情况下,平面文件可能更快,但数据库引擎使用了一代开发人员的经验,使数据访问更快、更可靠。例如,当脚本的两个实例试图将数据写入数据库时,只需考虑竞争条件和锁定。

    如果使用的数据量超过了csv文件中的几行,或者在文件(例如wiki的页面)中不容易管理,请使用数据库。它增加了一层并发症,但可以减轻你的头痛。

    想想做一个 SELECT * FROM posts WHERE MONTH(post_date) = "2010-03-10" 在平面文件上 迅速地 为了实现这一点,从头开始写是必要的。

        3
  •  2
  •   TomTom    16 年前

    什么是“平面文件数据库”?平面文件就是平面文件——像这样。如果说它是一个平面文件数据库,你会神奇地认为它具有数据库的一些特性——每个定义的平面文件都没有。

    MySQL的优点是什么 扁平文件?

    跳过这里的mysql——您要问的主要问题是“为什么要使用数据库”。

    我建议您研究一下性能(Sewarch操作——索引是有原因的),并查找术语“酸性条件”,以获得一个甚至模糊的概念,即数据库实际上是做什么的。

    平面文件并不能给你任何保证,几十年来的开发人员已经一次又一次地提出了所有的问题。

        4
  •  1
  •   jathanism    16 年前

    还有安全问题。如果你不适当地保护平面文件,它们可能更容易被曝光。尤其是在存储用户信息的情况下,在平面文件周围没有障碍。

    假设您的网站或应用程序垂直增长,平面文件也不会缩放,因为平面文件越大,读取时间越长。

    最后,在数据库已经很容易使用的情况下使用平面文件是一种简单的黑客行为。其他人都使用数据库,这不是“正确的方式”,所以我认为恰恰相反:为什么在MySQL上使用平面文件?在您决定使用平面文件之后,是否有其他人来维护您的应用程序?

        5
  •  1
  •   p.marino    16 年前

    我们需要更多的上下文。

    如果你的朋友正在阅读完整的页面(数据库中存储的广告“blobs”),那么是的,使用MySQL并没有什么帮助。如果他有粒度数据(包括,我不知道,博客文章,新闻项目,带有元数据的图像,订单细节),那么除非站点非常简单,非常静态,否则基于文件的方法很快就会变得太有限。

    您提出的解决方案有两大缺点:

    使用文件夹/文件名与在每个表上只有一个索引(在本例中是文件名)相同,因此搜索任何其他条件都需要很长时间。更不用说在一个目录中有很多文件会使操作系统负担过重。

    除此之外,按文件名划分的安全性有点安全风险,即使您将hashed-pwd作为URL的一部分。

    我在过去做过一些基于文件系统的中型应用程序(由于管理不当的要求,我们不能使用数据库),这很有趣,但当您浏览几百个文件时,这确实是非常有限的。即使是很小的数字,你也必须从一开始就耍花招,以便有任何希望让事情继续运作。

        6
  •  0
  •   AllenG    16 年前

    此外,不将所有用户信息存储在 Posts/ 文件夹,你如何得到所有的文章由约翰DOE写(例如)?在SQL中,它只是一个联合的select语句。对于平面文件,您要么将信息存储在实际的日志文件中,要么编写代码以自己执行连接和搜索操作。

        7
  •  0
  •   IMHO    16 年前

    举个例子:假设你有1000000个客户,有地址信息,你需要搜索和设置住在纽约的客户。如果您将每个客户存储在单独的文件中,那么您将需要读取所有1000000个文件,并查看客户是否属于该州。如果您将所有记录存储在一个大文件中,那么您需要读取整个文件并迭代以查找来自纽约的所有客户。

    在这两种情况下,你都放松了。

    对于像mysql这样的RDBMS,您将使用所谓的“set”操作或select语句,加上索引,引擎可能只读取比从NY查找所有客户所需数据多10/20%的数据。

    希望这有帮助

        8
  •  0
  •   Yandawl    16 年前

    在平面文件数据库中,数据冗余和原子性的缺乏是一个大问题,这些问题以指数形式表现为需要保存和引入查询延迟的数据越多,以及诸如更新/删除/插入异常等其他问题。

    具有规范化的关系数据模型有助于消除这些问题,方法是确保原子性,并且每个记录都是唯一可识别的(第一个正常形式),表中的每个字段在功能上依赖于主键(第二个正常形式),并且非键字段不共享表中其他字段的可传递依赖性。(第三正常形式)。

    关系数据模型绝不是实现这一点的唯一方法,甚至可能不是最好的方法,但它确实试图解决平面文件中固有的查询延迟和异常问题。

        9
  •  0
  •   atf.sgf    10 年前

    与flatfile相比,mysql有一些优势, 文件结构不好查询,但文件中的crud比mysql快,可以不使用mongo db等SQL数据库,结构更好,速度更快。 SQL和无SQL数据库之间有一些区别,但我认为最好不要使用SQL数据库而不是平面文件,还要注意,如果处理bigdata,没有SQL数据库比SQL肯定更好。