请问notion怎么合并单元格?
3 个回答
很典型的没有用懂Notion,也没有搞清楚自己的需求。
Notion里正经的表格使用的是数据库思维,而不是Excel的“给人看的表格”思维。事实上,Notion的“表格”,它的名字就是数据库。而在数据库当中,是没有“合并单元格”这个概念的。数据库里的数据表,从Access到MariaDB,一定都是横平竖直一格一格一格的。原因下面会说。
(你要说的是Note里嵌入的“简易表格”,那玩意儿过于弱鸟,用它替代Excel没有任何收益,事实上它仅仅是文本笔记当中的某种补充格式,比如记Note的时候发现一些信息用表格呈现更清晰明了,它压根就不是正经拿来存储、处理信息的。当然简易表格也可以转换为Database,不过前提是你自己作为用户已经想好了它的数据结构。)
从某种程度来说Excel也是一种数据库,但是常规意义上的“数据库”是存储了数据然后给其他软件调用的;而Excel这个数据库是存储了数据给人调用的。而人是众所周知的不靠谱、不规矩、喜欢瞎整,处理信息极度不精确,速度也非常垃圾,所以Excel有合并单元格、不对单元格内容进行严格限制和校验之类的没溜的设计。其中“合并单元格”这个就是非常典型的一个因为人类太没溜、太懒而产生出来的毒瘤(暴论)。
我下面就以一个简单的案例来说明数据库该怎么用,以及为啥合并单元格不被数据库所支持——以及为啥合并单元格是个毒瘤功能(暴论)。但是在开始之前,我得先介绍一下“数据库”当中的两个概念:记录、字段。
一般来说,一个数据库记录的是同一类、且会在相似的场合中使用的东西,日常生活中的通讯录就是一个极为典型的数据库。在这个数据库中,我们有一个一个一个的人,同时每个人都有自己的姓名、手机号、照片或者头像、邮箱、QQ号、微信号等等等。
那么,在这个数据库中,一个一个人就是一条条的“记录”,而每一个记录都有的姓名、手机号、头像、邮箱等等,这些就是用于描述这个记录的“字段”。
听起来是不是很像一些部门里的人员通讯录?很对头,就是这样。普遍来说这些通讯录都是用Excel表来写的。类似这种:
工号 | 姓名 | 部门 | 所属分公司 | 籍贯 | 年龄 |
---|---|---|---|---|---|
221 | 嬴政 | 土建工程部 | 陕西 | 陕西 | 39 |
202 | 刘邦 | 物流部 | 陕西 | 江苏 | 42 |
265 | 司马炎 | 人力资源部 | 河南 | 河南 | 22 |
581 | 杨坚 | 安保部 | 陕西 | 陕西 | 40 |
618 | 李渊 | 老干部活动中心 | 陕西 | 山西 | 61 |
960 | 赵匡胤 | 安保部 | 河南 | 河北 | 33 |
1368 | 朱元璋 | 宗教事务部 | 江苏 | 安徽 | 41 |
电子表是给人看的。某些场合,比如要统计哪些分公司的信息的时候,往往会大笔一挥,按照分公司合并单元格!
于是本来贼规整的一张表,变成了这样:
看起来,变得容易理解了,是吗?一眼就能看出河南分公司俩,江苏分公司一个,陕西分公司人才济济四个。
那好,现在再让你按籍贯来统计一下呢?
手忙脚乱地爬格子吧。这时候Excel老炮可能会邪魅一笑然后祭出筛选大法,嗯很好。现在将这份名单的完整版端上来,总计有494个人,统计一下姓啥的最多。嗯,按姓名排个序,然后一个个数?
但是如果用数据库的思维来搞,就很简单了。
首先,按照上面所说的记录和字段的定义,很明显,记录就应该是一个个人事档案,字段就分别是工号、姓名、部门、所属分公司、籍贯、年龄这几个。而且,其实还有一个很小的细节:在记录字段的时候,字段是越细越好,所以,姓和名其实是可以拆分开来的。这个用过Outlook的应该就知道这回事。
其次,需要注意,字段是有数据类型限制的,也可以做数据校验,比如工号,应当填数字,这里就不能填“李田所”,所属分公司和籍贯,应当在国内的省份里选择,就不能自己填“下北泽”,年龄可以限制为18-150的整数,这里也就不能瞎填个“114514”(这个年龄蹲马桶的黄金大只佬都够不着)。
至于“合并单元格”,想都别想,重复记录就重复记录。在人类看来,合并之后的单元格被视为“拥有同一个数值”,但是在数据库思维里,这绝对不允许。就算是两个相邻格子内容一样,也绝对不要合并,就忠实地填上重复的数值。
按照这样的方法,设计出来的这张表变成了上图这个样子。看起来一样啊?
这就要说起数据库和Excel另一个重要的区别了。Excel因为是给人看数据的,为了直观地呈现数据,往往允许用户对数据表从上摸到下从里摸到外,但是在数据库的概念里,这个,没门。因为数据库的数据,存储和查询是分离的。
事实上,Notion也好,国内的替代品FlowUS也好,这一切的鼻祖AirTable也好,都遵从某种意义上的数据库思维,甚至Excel自己的“表”,也是数据库思维,不允许随意合并单元格:
因为数据库它就是专门用来 存储 信息的,它不具备也不应当具备数据的 处理 、 查询 和 呈现 的功能。这也就赋予了数据库远远超过电子表的应用弹性。举一个例子,我现在正在写的这个回答,包括你看到的整个知乎,我没去专门搜索但是99.99%的可能性它是存储在知乎的服务器上运行的某个数据库里的,到你访问的时候系统将数据从数据库中调取出来,攒成一个页面甩给你电脑里的浏览器。这时候如果要做一个网页改版,比如产品经理突然脑抽要增加“按点踩数排序”这个功能,只需要改改前端就可以实现,数据库是不用动、也不能动的。
一般应用中的数据库也是一样的,数据表只用于信息的存储,要查看这些信息需要去专门设计查询和报表,而不是直接靠肉眼和极度不靠谱的人脑去处理原始的数据表。要不Excel专门设置了行数和列数限制呢——太多了的话人类那脑子根本看不过来。
但是AirTable和Notion也不能算是非常严格的数据库,从某种程度上说,Notion的Database是数据表和预设计的查询互相结合的低入门门槛的一类产品。算是数据库和Excel的某种融合。AirTable能火起来主要原因是它带有数据库的严谨、结构化、大批量数据管理方便,但是又尽可能像Excel那样直观。
举一个很简单的例子,还是上面那张人事表,一个分组筛选就能按照分公司来展开:
而且请注意,这不涉及对原始数据的调整,仅仅是新建了一个 视图 ,最初录入的那张表还在“默认视图”里躺着。
所以Notion的数据库从某种程度上也带有查询和存储分离的特征,这就赋予了Notion数据库很大的灵活性。比如用Notion来做任务管理,一个任务算是一条记录,可以设置它隶属于哪个项目、开始日期与截止日期、当前状态等等,然后呈现的方式可以是看板、时间轴、日历等等,我还会在Notion下面新建项目专项的笔记,然后引用这个任务列表,加上这个项目的过滤器,只显示任务列表当中和这个项目相关的事项。这些个Excel做不到吧。
所以Notion的数据库适合你已经非常清晰地想明白了你的整个表格的数据结构、以及计划如何去查询这些数据的时候用。我已经用这类产品(包括但不限于Notion、AirTable、钉钉文档的多维表)干过很多事情,包括但不限于:
- 个人事务管理
- 个人工作日志
- 整车特征整理和跟踪
- 某个反人类的游戏(X4 Foundations)中的生产状态跟踪、任务列表等
- 我那6台电脑上的常用软件版本与更新状态跟踪
- ……
而如果最后的目的就是为了做表,那大可不必折腾Notion数据库,钉钉文档或者石墨就可以了,或者继续用Excel。