文件系统隐喻

发布于 2024-11-02 19:54:25 字数 148 浏览 0 评论 0原文

我想知道如何在 SQL 数据库中表示文件系统隐喻(ntfs 基于 btree,对吧?)。 显然,数据以行的形式存储到表中,并且不使用 NTFS 存储方法;那么,NTFS(和其他 FS)如何在逻辑上工作来表示文件/文件夹层次结构? 有什么建议或参考吗?

感谢您的支持。

I'm wondering how to rapresent the file system metaphor (ntfs is based on btree right?) inside a SQL database.
Obviously data are stored as rows into tables and don't use the NTFS storing method; so, how NTFS (and other FS) logically works to rapresent the files/folders hierachy?
Any advice or references?

Thanks for the support.

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

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

发布评论

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

评论(1

逆光下的微笑 2024-11-09 19:54:25

如果您想要某种类型的数据库,存储在 DBMS 中,只需构建包含以下字段的表:

  • ID
  • 父 ID
  • 名称
  • 类型(目录或文件)
  • 修改日期(创建日期和上次访问日期是可选的)
  • 数据 (BLOB)

和就是这样。 ID/ParentID 可以让你建立一个层次结构,剩下的就是细节了。

大多数文件系统具有 ID/ChildrenIDList 的倒置结构,而不是 ID/ParentID,但这是由文件系统设计的细节引起的。如果文件系统由某些关系 DBMS 支持,那么拥有父 ID 可能更适合查找。

If you want to have some kind of database, stored in DBMS, simply build the table with the following fields:

  • ID
  • Parent ID
  • Name
  • Type (directory or file)
  • Modification date (creation date and last access date are optional)
  • Data (BLOB)

and that's it. ID/ParentID would let you build a hierarchy, and the rest is details.

Most filesystems have inverted structure of ID/ChildrenIDList instead of ID/ParentID but this is caused by specifics of filesystem design. If the filesystem is backed by some relational DBMS, then having a parent ID might be more optimal for lookup.

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