今天各种信息大部分仍然孤立在各个工具上。如以基于云的文档编辑器为例，其中页面是其最小的原子单位，信息被锁定在页面里、文件和文件夹中，这让人想起一个世纪前的工作方式。
Notion架构使得信息能够独立存在，且又不受其所在容器（如页面、文件或文件夹）的限制，将功能完全交给用户。
Notion框架是建立在Block块上的，在Notion中看到的所有内容都是一个Block块，文本，图像，列表，数据库中的行，甚至页面本身—这些都是块，这些块类似乐高积木，可以像乐高积木组合在一起，产生的整体效果要比积木部件的总和大得多。
Block块
就像乐高集中的乐高积木一样，块积木是表示概念编辑器内所有信息单元的单数形式。块的属性决定了如何呈现和组织信息。
每个块都具有以下属性：
- ID：每个块都可以通过其ID唯一标识。您可以在浏览器中URL的末尾看到页面块的ID。我们将随机生成的UUID（UUID v4）用于Notion中的ID。
- 属性：包含有关特定块的自定义属性的数据结构。最常见的属性是title，它存储块类型的文本内容，如段落、列表、当然还有页面标题。更精细的块类型需要其他或不同的属性，例如具有用户定义属性的数据库中的页面块。
- 类型：每个块都有一个类型，该类型定义了如何显示块以及如何解释块的属性。支持多种类型的块
除了描述块本身的属性之外，每个块还具有定义它们与其他块之间关系的属性：
- 内容：块ID的数组（或有序集），代表该块内的内容。
- 父级-块父级的块ID。父块仅用于权限。
块如何组合在一起？
就像乐高积木一样，概念积木可以与其他积木结合使用，从而使功能变得更加强大：例如完全针对您团队流程定制的路线图，跟踪进度并将所有项目信息保存在一个地方。我们对模块的各个方面进行组织，以确保它们做正确的事并生活在正确的地方，使用户能够连接它们，并进一步定制概念来解决他们的问题。
黑客新闻网友评论：
Salesforce和JIRA都做了类似的事情：它们的基础数据库模式非常通用，基本上是key和vale，从而允许在运行时定义任意逻辑模式。然而，在这两种情况下，他们最终并没有真正利用这种灵活性。这两个系统的逻辑模式都是非常普通的关系模式，可以直接在数据库上实现，并且性能要好得多。我想知道，Notion开发人员是否认真尝试在更传统的结构化架构上进行构建，并发现它确实不可行？
Notion的数据模型比文档编辑器（如Google Docs或Figma）背后的数据存储更为传统。块是Postgres中的“正好”行。使用JSON来实现属性的灵活性和用户定义的属性架构。
我认为这确实是独一无二的：Notion合并了读/写，对于这样的应用程序来说是非常革命性的。Wiki痴迷于读/写模式之间的切换。Drupal，Wordpress等是在后端中存在的写入模式，而读取模式则针对外部。
通过将读取/写入统一到一个连续的UI中，并具有非技术用户可以使用的内置关系数据库，Notion确实可以使人们创建该死的功能强大的自定义应用程序。
您会看到Notion看起来像互联网的下一版本。通过高度关注公司组织的内部网Intranet，他们将连接的工作区（“域”）的强大功能。Notion可被视为突破性的范式转变。
Notion具有一条清晰的路线，可以完全做到Coda最强大的功能（[令人难以置信的图表和公式]（https://coda.io/formulas））。他们可以使用Coda的嵌入式文本引用，因此您的文本可以实时链接到表中的信息。另一方面，Coda是从“简易的应用程序生成器”方法开始的，例如Retool for Excel专家。这是出色而强大的功能，但是UX在消费者和创作者之间建立了更大的分界线。
另一方面，Coda是从“简易的应用程序生成器”方法开始的，例如Retool for Excel专家。这是出色而强大的功能，但是UX在阅读者和创作者之间建立了很大的分界线。使用Notion感觉就像普通的文字处理程序，足以使普通用户开始疯狂地做他想做的却没有意识到。
我曾尝试将其用于个人笔记，但是它的速度和脱机性使我无法真正使用它。但是我认为，对于需要协作文档/ Wiki /融合式工具的组织来说，这是最佳选择。
我需要一个可以同步，可以离线工作，可以帮助捕获结构化数据，快速灵活的系统并具有出色的链接功能的系统。我目前正在使用Obsidian.Md。我使用Ulysses在iPhone + iPad上进行访问和编辑。我喜欢它是基于markdown的，链接非常容易，而且一切都很快。
一段时间以来，我一直在考虑从Evernote迁移到Obsidian / Notion /其他竞争对手，因为Evernote的UI一直在变差，这再次证实了我的观点，即Obsidian处于领先地位。
我是唯一认为数据模型非常复杂的人吗？它与基于文档的数据模型相比如何？各自的优缺点是什么？
你并不是唯一的一个。文档模型的主要问题是存储。文件可以增长到多大？您如何坚持下去，并在其中做些小改动？您如何处理非常流行的“热门”文档？在文档之间移动数据或使文档的一部分引用另一个文档的部分很复杂。复杂性来自构建查看文档切片的派生数据。
使用面向块的模型，记录的大小要容易得多。在文档之间引用或移动数据更容易，但是反过来，由于您的单个记录的范围较小，因此您需要执行此类递归欺骗。复杂性来自将数据块组合在一起构成文档的派生数据。
我听说有一种谣言：整个Notion都在一个未分片的数据库上运行。如果为真，那么我必须假设它们的堆栈中有大量的技术债务。这也可能是一个警示性的故事：说明当您将太多的早期决策误认为“过早的优化”时会发生什么。您一开始的用户量上升很快，但几年之后，您就陷入了所产生的所有债务中。
这就是我使用Obsidian的原因。https://obsidian.md/，所有数据都是本地存储的markdown文本文件，没有锁定到像Notion特定平台。
Notion对于发布公司文档，政策，手册，公告等非常有用。邀请员工作为“家庭客人”，无需任何额外费用。
我们还使用具有各种视图的Notion数据库来跟踪客户，销售渠道，奖励等等。
当我们吸引新客户时，我们会通过模板快速创建一个个性化的欢迎页面，其中包含他们的服务协议和其他一些内容的嵌入式副本。概念可以生成公共链接，因此我们可以立即发送此链接，并且会给人留下深刻的印象。
但是性能不是很好，但是对我们来说是如此有用，我不介意。我确实希望他们尽快提供离线版本，这是我目前最大的愿望。