Java XML vs SQL vs 自定义数据存储

发布于 2024-12-28 20:34:50 字数 493 浏览 5 评论 0原文

我正在为我的女朋友编写一个软件,并且正在努力在永久存储方式之间进行选择。由于应用程序主要围绕存储数据展开,因此这是一个相当重要的问题。

我的具体需求是:

  • 不断扩展的数据集占用空间小,可以轻松超过 10,000 个条目
  • 易于通过代码访问,易于移植到其他语言(以防我将来用另一种语言编写前端)
  • (可选)简单直接访问,以便可以进行手动编辑
  • 基于文件的存储是首选,因为它大大增加了数据的可移植性。

我考虑过 XML,它主要在第二点和第三点上失败,但在第一点上也有一点失败(我不确定 XML 的可扩展性到底如何,我没有做过任何测试)。

我也考虑过 SQLite,但它需要第三方库才能与 Java 正常工作(据我所知),并且在第三点上也失败了,因为直接访问是不可能的。

就定制而言,我真的宁愿避免它,因为重新发明轮子通常被认为是一件坏事®,但如果它确实是最好的选择,那么我会考虑它。

注意:我知道这可能是

I am writing a piece of software for my girlfriend and I'm struggling to choose between ways of permanent storage. Since the application revolves heavily around storing data, it's a fairly important issue.

My specific needs are:

  • Small footprint for a constantly expanding dataset that could easily exceed 10,000 entries
  • Easy to access from code, easy to port to other languages (in case I write a front-end in another language in the future)
  • (Optional) Easy to access directly, so that manual editing can be performed
  • File-based storage preferred, since it greatly increases the portability of the data.

I've considered XML, which fails mostly on the second and third points, but also a little on the first point (I'm not sure how scalable XML really is, I've not done any tests).

I've also considered SQLite, but it requires a third-party library to work properly with Java (as far as I'm aware) and also fails on the third point, since direct-access is impossible.

As far as bespoke is concerned, I'd really rather avoid it since re-inventing the wheel is generally considered a Bad Thing®, but if it really is the best option then I will consider it.

Note: I know this is a possible duplicate of Best data storage method for small personal application(SQL Database, XML, or other file type) but that one's favoured answer is SQLite, and there is a difference between C++ and Java where SQLite is concerned, so I figure this question is sufficiently different. Correct me if I'm wrong.

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

扫码二维码加入Web技术交流群

发布评论

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

评论(3

梦魇绽荼蘼 2025-01-04 20:34:50

对于关系数据之类的东西,我更喜欢 H2 数据库引擎。 HSQLDB 也可以做到。它将能够比 XML 或 JSON 更轻松地查询数据。将其视为一个高级 SQLite,可以在服务器模式下运行并可以轻松地通过外部工具访问(实际上是通过 H2 提供的)。

如果您的数据是图形结构的,请查看 neo4j

For something like relational data I'd prefer H2 database engine. HSQLDB could also make it. It will be able to query the data more easily than XML or JSON. Think of it as an advanced SQLite that can run in a server mode and be accessed by external tools easily (actualy delivered with H2).

Look at neo4j if your data is graph-strucutred.

温柔嚣张 2025-01-04 20:34:50

通过 ODBC 访问数据库可以减少代码对数据库技术的依赖,因为大多数数据库都有 ODBC 驱动程序。

Accessing a db through ODBC makes the code less db-technology dependent, as most databases have ODBC drivers.

不即不离 2025-01-04 20:34:50

最后,我选择了类似 JSON 的定制解决方案,因为文件使用标准化格式对项目来说并不重要。

我认为任何基于 SQL 的解决方案对于这个项目来说都太重量级了,但是数据本质上是表格形式的,所以我可能会考虑将来切换存储模式(编写代码以便可以轻松修改永久存储方法,这我建议将其作为其他在存储方法之间进行选择时遇到问题的人的一种操作方法)。

In the end, I opted for a bespoke JSON-like solution since it wasn't important to the project that the file use a standardised format.

I think any SQL-based solution would have been too heavyweight for this project, however the data is tabular in nature so I might consider switching storage modes in the future (the code is written such that the permanent storage method can easily be modified, which I would recommend as a modus operandi for other people who have a problem choosing between storage methods).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文