数据库对于产品经理来说是一个既熟悉又陌生的概念，虽然产品设计中的数据基本都要与数据库交互，但平时的工作中也很少接触到数据库的具体操作和细节。本文作者通过4个数据库语句，介绍了数据库对产品数据增、删、改、查设计的指导意义，希望能给你带来帮助。
都说产品经理要懂数据库，那么今天就通过4个数据库语句，来讲讲了解数据库对产品数据增、删、改、查设计的指导意义。
数据库，对于产品经理来说，是一个既熟悉又陌生的概念。熟悉是因为产品设计中的数据基本都需要与数据库交互，陌生是因为平时工作中很少接触到数据库的具体操作和细节。但是，了解一些数据库的基本知识和常用语句，可以帮助产品经理更好地理解数据的来源和流向，更有效地沟通数据需求和问题，更快速地验证数据分析的结果。因此，产品经理需要懂得一定的数据库知识，才能更好地发挥数据在产品设计中的价值。
我们先通过一张图来简单了解一下数据库是什么。
数据库是一种用于存储和管理数据的软件系统。数据库中的数据通常按照一定的结构组织，形成表（table）和字段（field）。表是数据的集合，字段是数据的属性。访问用户（user）是指可以对数据库进行操作的人或程序，例如查询、插入、修改或删除数据。访问用户需要通过数据库管理系统（DBMS）来连接数据库，并遵循数据库的安全规则和权限设置。
了解以上的信息，我们就可以进入正题了。
INSERT INTO table_name VALUES(value1,value2,value3);
以上是数据库的插入语句，它表示往指定的数据表中新增一条新数据，它对应的前端操作就是用户在系统中的“新建”操作，比如便签应用中新建一条新便签，或者电商平台中提交一笔新订单等。
数据库插入语句的执行效率受多种因素的影响，其中最主要的有数据量和操作的数据表数量。数据量越大，插入语句需要处理的数据越多，因此执行时间也会越长。操作的数据表数量也会影响插入语句的效率，因为每个数据表都需要进行索引更新、约束检查等操作，这些操作会消耗系统资源和时间。
因此，产品经理在设计需要收集数据量较多的表单的时候，一般建议做分步填写保存。例如以下某网站的认证流程。
分步填写保存的好处是：
DELETE FROM table_name;
以上是数据库的删除语句，它表示从指定的数据表中删除数据。它对应的前端操作就是用户在系统中的“删除”操作。比如删除便签、删除订单等。
删除无论对于什么样的系统，都是一个危险操作，一般删除后的数据都无法找回，是一个不可逆的操作，因此要求产品经理在设计删除操作功能时，需要尽可能让用户意识到此操作的危险性，引起用户的关注，关于这块，有兴趣的用户可以参阅：《谁动了我的文案：一个删除确认文案，难倒多少产品大汉》。
以上说的是传统的“硬删除”操作，后来随着人们对数据越来越重视，对于在数据库中删除数据的行为慎之又慎，因此出现了一种新的操作，叫做“软删除”。
软删除是一种数据保护技术，它可以使数据在被删除后仍然保留在数据库中，但对用户不可见。软删除的好处是可以恢复误删的数据，或者进行数据分析和审计。软删除的实现方法有多种，例如使用标记字段、使用时间戳、使用单独的表等。
换句话说，软删除是“假删除”，并不是真正意义上的删除数据，而是将要删除的数据标记为“已删除”的状态，在前端查询的时候，这些数据不会被查出来，从用户的角度来看，这条数据就是已经删除掉了。
软删除有以下好处：
同时也有以下弊端：
因此，产品经理应该根据不同的业务场景来区分哪些数据应该软删除，哪些数据可以硬删除，不应该“一刀切”地全部做成软删除或硬删除的设计。
UPDATE table_name SET column1=value1,column2=value2;
以上是数据库的更新语句，它表示将数据表中的目标字段内容修改为指定的内容。它对应的前端操作就是用户在系统中的“修改”或“更新”操作。比如修改便签内容，或更新订单状态等。
更新语句的执行效率和插入语句一样，主要受限于更新的数据量和操作的数据表数量，同时也受限于每条语句需要更新的字段数量。因此，产品经理在设计修改功能的时候，建议与“新建”一样，考虑按照业务或信息属性分开修改。
如下图是某平台个人中心的界面截图，常规资料、密码设置、更多资料分别在不同的标签中填写和保存，而不是全部放在一个长页面中进行修改。
下图是另外一个平台个人中心的界面截图，也是相似的设计，不过这个平台的设计更加激进，是按每个字段分开修改的，这种操作效率比较低，但针对个人资料的修改，倒是无伤大雅，毕竟个人资料这些信息，一旦填写之后，基本不会修改或很少修改，修改时也只是修改其中的某个信息，但在其他的业务场景下，采用这种设计时需要谨慎，一般建议按业务模块或信息属性分类修改，像这种按字段分开修改的设计，只适用于字段较少的场景。
更新语句的执行效率也受单个语句更新的字段数量影响，我们都知道，在进行修改操作的时候，系统都会先将之前的数据读取出来并让用户在此基础上进行修改并保存。
如下图，一般情况下，我们在修改信息的时候，哪怕只是改了其中某个字段的某个字，但系统在执行更新语句时，却需要更新全部字段，这个过程对用户而言是没有感知的，而对系统却是实实在在花费了时间去执行，如果更新的字段足够多，用户也会有明显的感知：明明我只改了一个字，为什么还是需要保存那么长时间？
因此，在某些修改信息的场景下，产品经理也会要求研发工程师先判断哪些字段是被用户修改过的，针对没有修改过的字段，在执行更新语句时，就不更新对应字段的数据。当然，对字段是否被修改进行判断，也会花费一定的时间，所以，产品经理应事先与研发工程师经过沟通后，再确定具体使用什么样的方案更合适。
SELECT * FROM table_name;
以上是数据库的查询语句，它表示从指定数据表中查询所有数据。它对应的前端操作不一定是用户在系统中进行搜索，比如进入订单页面就会看到所有订单，这个时候虽然用户没有进行搜索，但是系统依然需要在数据库中查询出订单数据。
查询是系统中最常用的操作，我们在系统中看到的所有来自数据库的数据都是通过查询得到的。以上提到的3个语句也经常要跟查询语句一起用，比如注册账号时，在往数据库添加新的账号信息前，需要先查询账号存不存在；修改和删除数据时，需要先从数据库中查询到目标数据，才能够进行修改和删除操作。
查询同样受限于数据量、查询的数据表以及查询的字段数量，产品经理在设计查询功能时，要求根据业务只查询必要的字段，而不是动不动就一次性将数据表中所有的字段都查出来。比如我们可以看到很多电商平台的订单列表，进入订单列表的时候，我们并不是看到订单的所有信息，而是订单的简要信息，比如订单号、金额、产品名称和封面图等，当我们点击订单之后，才会看到更多的信息，比如地址、物流、付款方式、价格组成、发票、各个节点的时间等。
另一方面，产品经理设计查询功能时，应尽可能减少聚合搜索的设计。
如下图所示某业务平台的订单搜索模块，该平台通过一个搜索框，就可以对订单的多个信息进行搜索，在这种情况下，当用户进行搜索的时候，系统需要同时对多个字段进行查询，甚至可能要同时对多个数据表进行查询，这种查询是非常耗费资源和时间的操作。
设计时，建议采用下图这种，将每个字段分开，只查询用户输入了内容的条件，并且每个输入框只针对某个数据表的某个字段进行搜索，比如用户只输入了手机号，系统就只需要查询手机号这个字段，可以有效提升搜索效率，并且减轻服务器的负担。
当然，这并非说聚合搜索就是不可取的，相反，它对提升用户的体验有非常好的效果，所以需要根据场景进行设计。一般建议 B 端的产品尽可能减少聚合搜索；C 端产品，在适当的位置可以采用聚合搜索；而移动端的产品设计，基本上都会优先考虑采用聚合搜索，因为移动端屏幕小，展示一堆的查询条件对用户来讲体验非常糟糕，但是，在设计查询条件时，还是要根据实际的业务场景，尽可能减少聚合搜索的字段数量和数据表数量。
通过以上4个语句，我们已经把产品数据中的增、删、改、查都讲完了，但以上所讲到的内容，还缺少一个关键，就是“约束”。
新增数据时没有约束，就会往数据库添加相同的数据，如果是在注册场景下，没有增加判断注册账号是否存在的约束，那么就会出现相同的账号；
删除数据时没有约束，就会将整个数据表中的所有数据删除掉；
修改数据时没有约束，就会将整个数据表中的所有数据都改成相同的值；
查询数据时没有约束，会影响数据的查询速度和查询时间。
对于数据库语句而言，这个“约束”，就是“WHERE”，一个语句后面带上“WHERE”，表示是这个语句执行的约束条件。
比如下方的语句表示删除 ID = 1 的数据：
DELETE FROM table_name WHERE ID = 1;
如果没有添加这个约束条件，那么执行删除语句的时候，就会将整个数据表内的数据删除掉，可想而知，这个后果是多么严重。
因此，产品经理在进行与产品数据交互有关的设计时，一定要在需求文档中写清楚约束条件，比如新增数据时，哪些情况下不允许新增。如果没有这些约束条件，对数据而言，造成的后果，可能是灾难性的。
以上便是本文全部内容，感谢阅读。
专栏作家
产品锦李，公众号：产品锦李（ID：IMPM996），人人都是产品经理专栏作家。不务正业的产品经理和他的产品设计。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。