将应用程序配置从 Windows 注册表迁移到 SQLite

发布于 2024-08-30 09:58:39 字数 231 浏览 1 评论 0原文

目前,我正在致力于标题行中提到的迁移。问题是保存在注册表中的应用程序配置具有树状结构,例如:

X
|->Y
   |->Z
      |->SomeKey someValue
W
|->AnotherKey anotherValue

等等。

如何在 SQLite(或任何其他数据库)中建模此结构?如果您有类似问题的经验,请发帖。提前致谢。

Currently, I am working on the migration mentioned in the title line. Problem is application configuration that is kept in registry has a tree like structure, for example:

X
|->Y
   |->Z
      |->SomeKey someValue
W
|->AnotherKey anotherValue

and so on.

How can I model this structure in SQLite (or any other DB)? If you have experience in similar problems, please send posts. Thanks in advance.

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

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

发布评论

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

评论(3

时光与爱终年不遇 2024-09-06 09:58:39

Baris,这种结构类似于目录/文件结构。
您可以使用目录上的简单父子关系以及与目录相关的键值对对此进行建模。

类似

Directory:
id integer auto_increment;
name string not null;
parent_id integer not null default 0;

Property:
id integer auto_increment;
key string;
value string;
directory_id integer not null;

这样,您可以通过查看 WHERE Parent_id=someid 来解决根目录搜索parent_id=0 的目录、子目录的问题,并查找该目录上寻找directory_id=someid 的属性。

希望这有帮助:)

Baris, this structure its similar to a directory/file structure.
You can model this with a simple parent<>child relationship on the directories and key value pairs relatade to the directory.

Something like

Directory:
id integer auto_increment;
name string not null;
parent_id integer not null default 0;

Property:
id integer auto_increment;
key string;
value string;
directory_id integer not null;

With this you can address the root directories searching for directories with parent_id=0, child directories by looking at WHERE parent_id=someid and for properties on that looking for directory_id=someid.

Hope this helps :)

余罪 2024-09-06 09:58:39

在关系数据库中表示层次结构非常容易。您只需使用自我引用即可。例如,您有一个类别表,其中有一个名为 ParentCategoryId 的字段,该字段要么为 null(对于叶类别),要么为父类别的 id。您甚至可以设置外键来强制执行有效的关系。这种结构在代码中很容易遍历,通常通过递归,但在编写 sql 查询时却很痛苦。

对于注册表克隆来说,解决此问题的一种方法是使用注册表项路径作为密钥。也就是说,有一个条目,其中路径是“X/Y/Z/SomeKey”,值是“someValue”。这将使查询更容易,但可能无法按照您喜欢的方式表达层次结构。也就是说,您将只拥有值,而不拥有层次结构的整体结构。

最重要的是,您必须妥协才能将具有未知级别数的层次结构映射到关系数据库结构。

Representing hierarchies in a relational database is pretty easy. You just use self-references. For example, you have a category table that has a field called ParentCategoryId that is either null ( for leaf categories) or the id of the parent category. You can even setup foreign keys to enforce valid relationships. This kind of structure is easy to traverse in code, usually via recursion, but a pain when it comes to writing sql queries.

One way around this for a registry clone is to use the registry key path as the key. That is, have an entry where Path is "X/Y/Z/SomeKey" and Value is "someValue". This will query easier but may not express the hierarchy the way you might like. That is, you will only have the values and not the overall structure of the hierarchy.

The bottom line is you have to compromise to map a hierarchy with an unknown number of levels onto a relational database structure.

千鲤 2024-09-06 09:58:39

当您想要存储层次结构时,以前的海报提到的自引用表很不错,但当您开始选择树的叶子时,它们就变得不那么有吸引力了。

  1. 您能否阐明从配置中检索数据的用例?

  2. 您要立即加载整个配置还是单独检索每个参数?

  3. 叶节点的深度有多任意?

Self-referencing tables mentioned by previous posters are nice when you want to store an hierarchy, they become less attractive when you start selecting leaves of the tree.

  1. Could you clarify the use-case of retrieving data from the configuration?

  2. Are you going to load the whole configuration at once or to retrieve each parameter separately?

  3. How arbitrary will be the depth of the leaf nodes?

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