我觉得最合适的方法是支持在数据库字段里获取内置属性和自定义属性然后编辑，这种情况下字段名不等于属性名，属性名也不需要支持中文了。

https://ld246.com/article/1695732053015

https://ld246.com/article/1714489027667

附议，向anytype学习！

这样可以提高灵活性，数据库由局部属性和全局属性共同构建，可以降低属性维护的困难度以及重复输入的频率。另外将书签、标签等内置属性视为全局属性时，甚至可以将书签、标签面板融合到一个专门的属性反查条目的面板中，提供筛选、搜索等操作。

我有一点不同的看法，tana的supertag只是叫supertag，虽然是通过#进行输入，但它实际上是一个通过全局属性组织起来的数据库的视图，在选中对应tag后这个tag就不再是行内文本了，而是以独立元素的形式被定死在块末尾，与思源目前的添加到数据库类似，并不能通过退格键直接进行修改。

换句话说tana选择了打标签作为添加到数据库的快捷方式，当然tana的数据库和思源的数据库还是有许多区别的。

可以参考下我这篇回答🙏🙏：#11371 (comment)

以上回答仅供参考，也不是说tana就这么简单哈。

添加到数据库 和 #标签#

这两个功能就不可能是一样的， 改成 SuperTags 虽然都是数据库的形式，但是 SuperTags 是为了让标签功能更强大，他不应该取代 添加到数据库 混为一谈，功能定位也不一样

我好像知道我俩的分歧在哪里了，Sa以为我提这个FR是想把数据库改成动态的。

其实我在这个FR下，提的是

1. 现有多个数据库之间的属性复用（静态）
2. 自定义属性的复用
3. 融合书签和标签面板并改造为全局属性面板，通过独立的面板对全局属性进行反向查询、筛选、搜索（动态）

所以其实不太冲突。

刚才理解错了这里重新总结一下需求

1.自定义属性支持中文名
2.数据库支持调用自定义属性为一列
3.自定义属性应该有多种类型(复选框，资源，多选，单选)
4.数据库被调用的属性应该支持编辑

我也总结一下这个FR具体的需求，主要需求集中在属性而非数据库，个人认为这样改动带来的收益是非常高的。

考虑的方面

在提议时我考虑了下面这些内容：

1. 是否能以较小的改动成本大幅度降低数据库的维护难度
2. 内置、自定义、数据库属性之间互相不通用的问题是不是有比较好的解决办法。
3. 单独增强对标签、书签里的某一特性并不划算，那我们有没有办法统一这些属性，做一个全局属性通用的动态查询面板。
   1. 这又让我想到了另一个方面，既然都到这一步了，那直接增强搜索是不是比新做一个面板更加合适？可以同时根据块类型和块属性进行筛选。而且搜索功能本身也有持久化存储搜索条件的功能。
4. obsidian、logseq、capacities等软件的用户，在以yaml作为markdown元数据迁入时，是否有保留属性的可能性（这里只是说的可能性，没有任何修改思源导入功能的想法，具体意思是用户有需求就自己搞去）

主要提议

我的主要提议是将内置、数据库、自定义属性合一，只根据作用范围的不同分为全局属性（工作空间）和局部属性（数据库）。

1. 为属性的设置面板添加两个开关
   1. 设为全局属性
   2. 在 DOM 中显示（作为 CSS 选择器）
2. 每一个全局属性作为一个单独json文件存储
   1. 它不存储具体的块
   2. 只存储一些需要持久的信息
      1. 属性值
      2. 一些持久化的筛选条件：为用户进行动态查询提供可能性。
3. 对数据库来说，仅需做到
   1. 开启 设为全局属性 后，对应列的属性值与全局属性的属性值进行同步增删修改
   2. 添加属性列时，全局属性作为预选项提供
4. 而有了全局属性后，
   1. 搜索功能可以更进一步，同时支持筛选块类型和块属性。
   2. 自定义属性：可以比较好地解决自定义属性缺少的
      1. 属性类型
      2. 中文支持：只有属性名为英文时才能开启 在 DOM 中显示（作为 CSS 选择器），这个交给用户自行决定。
      3. 复用属性和属性列：救救脑子吧，不想再记住这些东西了
   3. 内置属性：将内置属性、文档标签、题头图、题头图标作为思源内置的全局属性提供给用户
      1. 可以在数据库中方便地进行增删修改
      2. 如果要支持画廊视图，那么基于块的数据库多半会需要题头图和题头图标作为属性存在
      3. 文档标签，可以当作内置的标签属性来使用
      4. 块的行内标签，行内标签与内置标签属性进行同步增删修改，可在数据库视图上与文档标签功能统一。
   4. 全局属性的动态反查汇总：不管是通过融合书签标签的全局属性面板，亦或是通过对搜索功能的改进来实现。只要存储了用户自行设置的筛选方案（例如添加其他属性作为筛选条件），调用就会非常方便。

支持一下，整合属性确实方便维护，减少四处跑的压力，也方便直接批量管理文档元数据

感谢提议，但是大改是不太可能了，其中有个复杂的问题是一个块可以绑定多个库，这种情况下属性的作用域管理非常困难，所以我们是通过模板字段解决单向全局属性场景的，这也是复杂度和扩展性上面权衡的结果。

感谢D大回复，但我不是特别理解为什么绑定多个库会让属性的作用域管理非常困难。在提议之初就考虑到数据库的实现非常复杂且推出已经有一年的时间，任何大改都是不现实的，因此这个FR其实是关于属性而非数据库的。

换句话说，对数据库的改动仅限于：

• 当数据库中某一个字段使用全局属性时，与其他使用该全局属性的数据库同步属性值的预选项
  
• 若一个块绑定多个库，且用户主动对部分数据库添加同一个全局属性。考虑到其他软件的已有实现，一个块作为一个条目时，其中全局属性的属性值应该是相同且同步更新的
  
• 即使是一个块绑定多个库，块中已使用的全局属性也只作为预选项存在，不会自动添加。
  

而这个FR更多的是希望

1. 通过全局属性这一特性，大幅度降低用户维护数据库属性所耗费的心力。
2. 将自定义属性的选择器特性、内置属性作为全局属性的一部分来提供，这样即提供了数据库属性那样舒服的编辑体验，也利于维护和管理
   1. 自定义属性现在受限于DOM对中文的限制
   2. 在数据库中，对条目的命名、别名、书签、备注等进行快速批量的增删修改
   3. 如果以后有画廊视图，那么即便思源是基于块的，题头图和题头图标属性估计也是不可少的
      1. 如果单独使用资源属性，对文档块来说，管理使用起来估计是个大麻烦
      2. 在嵌入块等多个方面有更多样式可用
3. 提供迁入的可能性
4. 在搜索中善用属性的可能性
   1. 以块属性为筛选条件，进行筛选
   2. 以块属性为搜索内容，辅以其他块属性、块类型作为筛选条件进行搜索

总之老大还是考虑一下吧😁😎

真的很需要全局数据库，有没有这个功能，完全是质的变化。

支持

就目前的使用来看，自定义属性和数据库属性有种割裂感，比如markdown的yaml导入思源生成的是自定义属性，而数据库中能编辑操作的是数据库属性。 假设用户从自带的md文件迁移入思源，想维护一个基于原来md的yaml内容的数据库，如果属性之间能连通的话体验会更好。

就目前的使用来看，自定义属性和数据库属性有种割裂感，比如markdown的yaml导入思源生成的是自定义属性，而数据库中能编辑操作的是数据库属性。 假设用户从自带的md文件迁移入思源，想维护一个基于原来md的yaml内容的数据库，如果属性之间能连通的话体验会更好。

不知道是否涉及全局属性的功能，但如果有以下功能的完善，相信会有更好的体验：
1，三种属性在md文件（yaml）的导入和导出
2，三种属性在笔记页面有更好的展示
3，三种属性在数据库中的可同步编辑
4，属性上有争议方面的可以交给用户自己选择

真的很需要全局数据库，有没有这个功能，完全是质的变化。

确实，看大伙搁链滴整JB没逑用的数据库视图，还不如统一属性呢

顶，支持

顶一个，支持一下，全局属性真的很重要（可以自己选择哪个字段作为全局属性，哪个字段作为独立的属性就更棒了）