用于分层数据集的高效便携式数据库 - Json、Sqlite 还是?

发布于 2024-10-10 10:00:50 字数 1486 浏览 7 评论 0原文

我需要创建一个包含分层数据集的文件。有问题的数据集是文件系统列表(目录名称、每个目录中的文件名/大小、子目录……)。

我的第一直觉是使用 Json 并使用路径展平层次结构,这样解析器就不必递归太多。如下例所示,每个条目都是一个路径(“/”,“/child01”,“/child01/gchild01”,...)及其文件。

{
    "entries":
    [
        {
            "path":"/",
            "files":
            [
                {"name":"File1", "size":1024},
                {"name":"File2", "size":1024}
            ]
        },
        {
            "path":"/child01",
            "files":
            [
                {"name":"File1", "size":1024},
                {"name":"File2", "size":1024}
            ]
        },
        {
            "path":"/child01/gchild01",
            "files":
            [
                {"name":"File1", "size":1024},
                {"name":"File2", "size":1024}
            ]
        },
        {
            "path":"/child02",
            "files":
            [
                {"name":"File1", "size":1024},
                {"name":"File2", "size":1024}
            ]
        }
    ]
}

然后我认为为每种文件类型一遍又一遍地重复按键(“名称”,“大小”)很糟糕。所以我找到了这篇关于如何使用 Json 的文章,就好像它是一个数据库一样 - http://peter.michaux.ca/articles/json-db-a-compressed-json-format

使用该技术,我将拥有一个像“Entry”这样的 Json 表,其中包含“Id”、“ ParentId”、“EntryType”、“Name”、“FileSize”,其中“EntryType”对于目录为 0,对于文件为 1。

所以,此时,我想知道 sqlite 是否是更好的选择。我认为文件大小会比 Json 文件小很多,但如果我使用本文中的 Json-DB 压缩格式,它可能可以忽略不计。除了尺寸之外,您还能想到其他什么优点吗?

I need to make a file that contains a hierarchical dataset. The dataset in question is a file-system listing (directory names, file name/sizes in each directory, sub-directories, ...).

My first instinct was to use Json and flatten the hierarchy using paths so the parser doesn't have to recurse so much. As seen in the example below, each entry is a path ("/", "/child01", "/child01/gchild01",...) and it's files.

{
    "entries":
    [
        {
            "path":"/",
            "files":
            [
                {"name":"File1", "size":1024},
                {"name":"File2", "size":1024}
            ]
        },
        {
            "path":"/child01",
            "files":
            [
                {"name":"File1", "size":1024},
                {"name":"File2", "size":1024}
            ]
        },
        {
            "path":"/child01/gchild01",
            "files":
            [
                {"name":"File1", "size":1024},
                {"name":"File2", "size":1024}
            ]
        },
        {
            "path":"/child02",
            "files":
            [
                {"name":"File1", "size":1024},
                {"name":"File2", "size":1024}
            ]
        }
    ]
}

Then I thought that repeating the keys over and over ("name", "size") for each file kind of sucks. So I found this article about how to use Json as if it were a database - http://peter.michaux.ca/articles/json-db-a-compressed-json-format

Using that technique I'd have a Json table like "Entry" with columns "Id", "ParentId", "EntryType", "Name", "FileSize" where "EntryType" would be 0 for Directory and 1 for File.

So, at this point, I'm wondering if sqlite would be a better choice. I'm thinking that the file size would be a LOT smaller than a Json file, but it might only be negligible if I use Json-DB-compressed format from the article. Besides size, are there any other advantages that you can think of?

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

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

发布评论

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

评论(2

青衫儰鉨ミ守葔 2024-10-17 10:00:50

我认为数据源的 Javascript 对象作为文件流加载到浏览器中,然后在浏览器中的 javascript 逻辑中使用将消耗最少的时间并具有良好的性能..但仅限于内容的层次结构大小有限。

此外,不将层次结构存储在其他任何地方并仅将其保留为 JSON 文件会严重限制数据源在项目中对客户端技术的使用......或强制转换为其他技术。

如果您正在构建一个纯基于 javascript 的应用程序(仅 html、js、css 应用程序),那么您可以将其单独保留为 JSON 对象.. 并限制您的层次结构大小.. 您可以将更大的层次结构拆分为链接 json 对象的多个文件。

如果您的项目中有像 php 这样的服务器端代码,
考虑到代码的可管理性和扩展性,您最好将数据存储在 SQLite DB 中,在运行时为有限级别的 json 层次结构创建 Ajax 从页面加载时的级别。

I think a Javascript object for datasource, loaded as a file stream into the browser and then used in javascript logic in the browser would consume the least time and have good performance.. BUT only until a limited hierarchy size of the content.

Also, not storing the hierarchy anywhere else and keeping it only as a JSON file badly limits your data source's use in your project to client-side technologies.. or forces conversions to other technologies.

If you are building a pure javascript based application (html, js, css only app), then you could keep it as JSON object alone.. and limit your hierarchy sizes.. you could split bigger hierarchies into multiple files linking json objects.

If you will have server-side code like php, in your project,
Considering managebility of code, and scaling, you should ideally store the data in SQLite DB, at runtime create your json hierarchies for limited levels as ajax loads from your page.

小耗子 2024-10-17 10:00:50

如果这是您的应用程序存储的唯一数据,那么您可以做一些非常简单的事情,例如将数据存储在易于解析/读取的文本文件中,如下所示:

File1:1024
File2:1024
child01
    File1:1024
    File2:1024
    gchild01
        File1:1024
        File2:1024
child02
    File1:1024
    File2:1024

文件获取文件:大小,目录仅获取其名称。缩进给出结构。对于稍微更标准但同样易于阅读的内容,请使用 yaml。

http://www.yaml.org/

两者都可以通过减小文件大小(但降低用户可读性)来受益gzip 压缩文件。

如果您有更多数据要存储,请使用 SQLite。 SQLite 很棒。

不要使用 JSON 来保存数据。这是浪费。

If this is the only data your application stores then you can do something really simple like just store the data in an easy to parse/read text file like this:

File1:1024
File2:1024
child01
    File1:1024
    File2:1024
    gchild01
        File1:1024
        File2:1024
child02
    File1:1024
    File2:1024

Files get File:Size and directories get just their name. Indentation gives structure. For something slightly more standard but just as easy to read, use yaml.

http://www.yaml.org/

Both can benefit from decreased file size (but decreased user readability) by gzipping the file.

And if you have more data to store, then use SQLite. SQLite is great.

Don't use JSON for data persistence. It's wasteful.

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