使用独立的 C++ 存储数据应用

发布于 2024-09-02 17:35:57 字数 528 浏览 17 评论 0原文

我使用 Apache、PHP 和 MySQL 进行 Web 开发和本地应用程序。在过去的几年里，我一直在慢慢学习 C++，并想在今年夏天构建一个应用程序。具体来说，我想制作一个“图书馆”应用程序，在其中可以存储有关我拥有的书籍、CD 和记录的信息。我知道存在这种类型的应用程序，但我想学习 C++，这似乎是一个很好的方法。

这里有几个问题：

是否可以创建一个不需要数据库来存储数据的独立应用程序？
如果上述问题 1 的答案是“是”，那么对于可能需要管理大量数据的应用程序来说，这样做是个好主意吗？
您建议将哪些数据存储选项与 C++ 应用程序一起使用？

谢谢！

更新嗯，对此有很多好的答案。这是一个非常棒的网站，有很多贡献者。事实证明，我现在可能真的不需要走 C++ 路线。我现在意识到，我最感兴趣的是编写一个可以充当“图书馆”组织系统的应用程序，比我对 C++ 更感兴趣。感谢大家的回答！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

羁绊已千年 2024-09-09 17:35:57

是否可以创建一个不需要数据库来存储数据的独立应用程序？

是的，您可以使用某种自定义文件格式来存储数据。

如果上述问题 1 的答案是“是”，那么对于可能需要管理大量数据的应用程序来说，这样做是个好主意吗？

这并不是一个好主意，除非您真的想了解如何在结构化文件中存储数据。

您建议将哪些数据存储选项与 C++ 应用程序一起使用？

我会看看 SQLite。它是一个数据库，但它不需要单独的引擎。

回复收藏 0 原文

过去的过去 2024-09-09 17:35:57

如果您不想使用数据库，您可能希望将数据保存到一个文件（或多个文件）中。如果是这样，问题可能是：哪种文件格式最好？答案取决于多种因素：

1）访问速度快、体积小且易于解析？答案是“二进制数据”。只需使用 fwrite 将数据直接按原样写入输出文件。有两个缺点：这些文件不是人类可读的，并且维护不同的版本很麻烦。如果您读取的数据不完全符合您的预期，您很快就会遇到麻烦。

2）人类可读且易于维护？这就是 XML 的用途。有现成的解析器，如tinyXML，它们是将数据写入文件的优秀工具。缺点是编写加载/保存例程需要更多时间（很多情况下）。

3) 为您完成这项工作的图书馆。 MFC 提供了 CArchive 类，但还有其他可能更好的工具可以执行此操作。

回复收藏 0 原文

看轻我的陪伴 2024-09-09 17:35:57

是的，
这取决于数据，“大量数据”是相对的，你可能会发现大约1000本书的信息可以存储在几个MB中，那么将其存储在数据库中就有点大材小用了，除非它是轻量级数据库，例如作为 sqlite
我建议坚持使用纯文本格式，例如 CSV 或 XML。

为了学习，不要使用数据库引擎会对你有很大帮助，除非你想学习 SQL 和关系数据库设计。
另一方面，使用数据库引擎将使开发更快、更容易，因为它会为不同的数据创建索引，以帮助您轻松高效地搜索。

所以这取决于你。

回复收藏 0 原文

我不吻晚风 2024-09-09 17:35:57

嗯……

当然，你可以这样做。

你所说的做法是回到 RDBMS 成功之前的时期。这并不难做到，但您可能会吸取一些经验教训：

在开始编码之前 - 或者至少在编写数据访问代码之前，请像要使用数据库一样进行数据库设计 - 什么数据你需要吗？您可以减少所需的属性（“字段”）数量吗？您图书馆中的媒体类型有哪些共同点？等等。
考虑使用目录树和文件名作为一种临时存储结构。如果您需要或想要管理超出程序当前能力的数据，这会将数据直接交给命令行实用程序。例如，书籍可能全部位于 books 子目录中，并且在该子目录中，您可以使用 ISBN 或标题作为文件名。我寻找可以使用 ls、dir 或 CLI 使用的任何内容自然排序为文件名的内容。
另一个不错的选择是将其采用 XML 格式。可能两者兼而有之 - 使用目录层次结构进行整体数据布局，并将图书馆条目数据放入 XML 格式的平面文件中。这在某些时候可能会很方便。
仅将数据以纯文本格式作为字符串 - 无二进制数据！这对于能够访问/操作程序外部的数据也很重要。
通过这样的策略，如果需要，您可以使用 grep、sed、lex 等系统工具对数据执行完全计划外的操作。
拥有一个功能 - 或编写一个单独的阅读器程序 - 遍历您的“数据库”并将其全部内容以纯文本形式输出，每个条目一行。您可能有一些选项告诉它要输出哪种媒体等。此外，还可以包含一个标志，让您设置输出属性之间使用的分隔符 - 逗号分隔是常见的选择，但您可能也只需要一个空格，回车、换行或其他任何内容。如果您将其设置为可选标志，让用户使用任何东西并提供您最喜欢的默认值，那么应该没问题。
模块化您的代码，以便您可以在以后选择时更换您的存储策略，而不必重新修改整个程序。您甚至可以提供多种存储策略。

这应该可以做到。

请注意，使用现代计算机硬件，您将管理的数据量不太可能成为性能或空间问题，因此不必担心节省几个字节 - 这不值得这么麻烦。

祝你好运，享受旅程。

Hmmm...

Of course, you can do this.

What you're talking about doing is stepping back in time to the period before the RDBMS became successful. This isn't hard to do but you might well take some lessons learned:

Before you begin coding - or, at least, before you write data-access code, do your database design as if you were going to use a database - what data do you need? Can you reduce the number of attributes ("fields") you need? What are the commonalities among media types in your library? etc.
Consider use of directory trees and file names as a bit of an ad-hoc storage structure. This will put the data directly into the hands of command-line utilities, should you need or want to manage the data beyond your program's present abilities. For example, books might all be in a books subdirectory, and within that, you might use ISBN or title as the file name. I look for things that will naturally sort as a file name using ls, dir, or whatever your CLI uses.
Another good choice would be to put it in an XML format. Possibly both - use a directory hierarchy for the overall data layout and put the library entry data in flat files in an XML format. This could turn out to be handy at some point.
Put the data ONLY in plain text format as strings - no binary data! This is important, again, for being able to access / manipulate the data outside your program.
With such a strategy, you can use system tools like grep, sed, lex and so forth to do completely unplanned things with the data, should the need arise.
Have a feature - or write a separate reader program - that walks your "database" and outputs its entire contents as plain text, one line per entry. You might well have options that tell it what kind of media to output, etc. Also, include a flag that lets you set the delimiter used between attributes for output - comma separated is a common choice, but you might also just want a space, a carrage return, new line, or whatever else. If you make it an optional flag to let the user use anything and provide your favorite default, it should be fine.
Modularize your code so you can replace your storage strategy later if you so choose and not have to re-hack the whole program. You might even provide multiple storage strategies.

This ought to do it.

Note that the amount of data you will be managing, with modern computer hardware, is not likely to ever become a performance or space issue, so don't worry about saving a few bytes - it's not worth the hassle.

Good luck, and enjoy the ride.

回复收藏 0 原文

赏烟花じ飞满天 2024-09-09 17:35:57

是的。
可以，但除非您的需求比看起来更专业，否则通用数据库管理器可能是更好的选择。
对于这样的事情，我会考虑使用可用的（许多）嵌入式数据库管理器之一。

鉴于您（显然）这样做主要是为了自学，而不是真正的使用，因此在没有数据库管理器来处理存储的情况下编写代码可能是有意义的。自己编写所有代码（稍微小心）通常会导致速度稍高，但代价是相当多的额外工作，并且通常会损失一些灵活性。从学习的角度来看，最大的问题是，您在此过程中学到的大部分内容仅适用于相当狭窄的情况（即，对于大多数典型的应用程序，您将想要使用数据库管理器，因此学会不做事很少能收获很多）。

一点也取决于您的预期用途/受众。如果您想一次支持多个用户，事情几乎立即就会变得困难得多（至少这样做是有效的）。如果您只对一个用户一次能够访问数据库感兴趣，那么事情就会变得简单得多。