SQL 和平面文件...和谐吗？
我只是在想，将应用程序的实际数据存储在平面文件中会有多快。
现在，您不能只是将所有内容存储在平面文件中......有时需要进行排序和搜索，并且递归地遍历目录和文件可能会很痛苦。
现在，想象一下，您将所有可搜索数据存储在数据库中，并且有一个指向数据文件的指针字段？
然而，这对于每个应用程序来说都是非常具体的 - 只要我所有可搜索的数据都存储在数据库中，为什么我应该将实际数据存储在数据库中？
（锁定，数据完整性除外）它会更快，我确信......但是多少，值得这样做吗？
I was just thinking, how quick it would be to store the actual data of an application in a flat file.
Now, you can't just go storing everything in a flat file... sometimes sorts and searches are required, and to go through directories and files recursively could be a pain.
Now, imagine, you stored all your search-able data in a database, and had a pointer field, that pointed to a data file?
This would be very specific per app, however- so long as all my search-able data is stored in the database, why should I store the actual data in a database?
(Locking, Data integrity aside) it would be faster, I am sure... but how much, and is it worth doing it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
除了搜索数据之外，您还经常希望在查询中执行其他操作。例如，您可能不会搜索名为 cost_center 的字段，但您可能有一个 case 语句，根据该字段中的信息以不同的方式处理事物。或者您可能需要将信息连接在一起。您可以根据一个字段中的信息更新另一字段中的信息。您今天可能不会搜索某个字段，明天需要搜索它。
正确设计的关系数据库可以轻松地处理 TB 级的数据。
坦率地说，您甚至不应该考虑“数据完整性”。如果没有数据完整性，就没有数据。
至于您想要的是否是一个好主意，这取决于您存储的数据类型以及您打算用它执行的操作类型。没有足够的信息可以肯定。
Well you often want to do things in queries beyond search on the data. For instance you might might not search on a field called cost_center, but you might have a case statment that processes things differently depending on the information in the field. Or you might need to concatenate information together. You might update one field based onthe information in another field. You might not search on a field today and need to search on it tomorrow.
A properly designed relational database can easily perform well with terrabytes of data.
And frankly you should never even consider "data integrity aside". If you don't have data integrity you don't have data.
As to whether what you want is a good idea, it depends on the type of data you are storing and the types of things you intend to do with it. There isn't enough information to say for sure.
那么“锁定，数据完整性除外”应该意味着更快的系统。如果你放弃约束，你应该提高性能。
但实际上，我认为它不会更快。 RDBMS 背后有大量的开发时间，这就是它们速度很快的原因。当然，例如，在高度并行的情况和利用其特性的场景中，非关系数据库的性能比它们更好。然而，你的想法并没有提供诸如利用并行性之类的改进...任何性能优势都将来自于放弃 RDBMS 的质量...
Well "Locking, Data integrity aside" should mean a faster system. If you drop constraints you should improve performance.
But in practical terms, I don't think it's going to be faster. There's lot of development time behind RDBMSs and that's why they are quick. Sure, non-relational databases are performing better than them in highly parallel situations and scenarios which take advantage of their qualities, for instance. However, your idea does not offer an improvement such as exploiting parallelism... any performance advantage would come from dropping the qualities of RDBMSs...
以及其他答案...
As well as other answers...
不需要仅仅为了执行搜索而实现 SQL 数据库。许多应用程序将其数据存储在 XML 中，您可以通过多种方式进行搜索，例如使用 Lucene。它的速度完全取决于数据的数量以及数据的结构 - 就像数据库一样。
它的执行速度非常快，但当您想要运行多个应用程序服务器时，事情可能会变得复杂。
There is no need to implement a SQL database just to perform searches. Lots of applications store their data in XML, and you can search in many ways, e.g., using Lucene. How fast it is entirely depends on the quantity of data and how you structure it - just like a database.
It can perform very fast, but can complicate things when you want to run more than one app server.
BTrieve 对于您所描述的至关重要。在 DOS 时代，它是一个非常快的数据库。
BTrieve was essential what you describe. Back in the DOS days it was a very fast database.