数据库是需求的直观反应和表现，因此设计时必须要切实符合用户的需求，要多次与用户沟通交流来细化需求，将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确，就要分析不确定的因素，设计表时就要事先预留出可变通的字段，正所谓“有备无患”。（2）、数据库设计不仅仅停留于页面demo的表面页面内容所需要的字段，在数据库设计中只是一部分，还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段，因此数据库设计绝对不是简单的基本数据存储，还有逻辑数据存储。（3）、数据库设计完成后，项目80%的设计开发在你脑海中就已经完成了 每个字段的设计都是有他必要的意义的，你在设计每一个字段的同时，就应该已经想清楚程序中如何去运用这些字段，多张表的联系在程序中是如何体现的。换句话说，你完成数据库设计后，程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。如果达不到这种程度，那当进入编码阶段后，才发现要运用的技术或实现的方式数据库无法支持，这时再改动数据库就会很麻烦，会造成一系列不可预测的问题。（4）、数据库设计时就要考虑到效率和优化问题 一开始就要分析哪些表会存储较多的数据量，对于数据量较大的表的设计往往是粗粒度的，也会冗余一些必要的字段，已达到尽量用最少的表、最弱的表关系去存储海量的数据。并且在设计表时，一般都会对主键建立聚集索引，含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时，还要考虑是否有必要采用存储过程。 （5）、添加必要的（冗余）字段像“创建时间”、“修改时间”、“备注”、“ *** 作用户IP”和一些用于其他需求（如统计）的字段等，在每张表中必须都要有，不是说只有系统中用到的数据才会存到数据库中，一些冗余字段是为了便于日后维护、分析、拓展而添加的，这点是非常重要的，比如黑客攻击，篡改了数据，我们便就可以根据修改时间和 *** 作用户IP来查找定位。（6）、设计合理的表关联 若多张表之间的关系复杂，建议采用第三张映射表来关联维护两张表之间的关系，以降低表之间的直接耦合度。若多张表涉及到大数据量的问题，表结构尽量简单，关联也要尽可能避免。（7）、设计表时不加主外键等约束性关联，系统编码阶段完成后再添加约束性关联这样做的目的是有利于团队并行开发，减少编码时所遇到的问题，表之间的关系靠程序来控制。编码完成后再加关联并进行测试。不过也有一些公司的做法是干脆就不加表关联。（8）、选择合适的主键生成策略
意见反馈是APP的基础功能，它是与用户互动、收集用户意见的重要渠道，其入口一般放置在关于页或设置页。
典型的意见反馈设计有两种：在线客服和反馈表单
在线客服
类似即时通讯功能，用户在下方输入文字，由人工或机器人进行回复，以便快速解决用户问题，多用于电商、SNS、游戏等领域。机器人回复，类似自动问答，根据提问关键字匹配问题库回复用户，比人工节约成本，回复相对生硬，不够人情味。
优点：快速响应，实时互动， 点对点，反馈高效，有趣。
缺点：问题过于零散，不便归纳整理分析，研发成本高。
建议采用第三方工具搭建即时通讯功能，节省开发成本。
反馈表单
简单点就一个内容输入框，或再加个上传附件、联系方式或反馈类型，这种设计略显机械。也有用选择题替代表问答题，或者选择题必填，问答题选填，让用户觉得填反馈花不了多长时间还很简单方便，发送反馈的几率会高得多。
相比在线客服，反馈表单形式固定化，方便归类整理分析反馈问题，研发成本低，大部分APP都采用这种。填写表单的设计要点：
1、表单不要太长，字段尽量少，减少用户输入；
2、不要让用户填写姓名、地址等信息；
3、反馈之后要有回复，不要杳无音讯，回复不要太官话和机械，要有人情味，让用户觉得他的反馈是有用的；
4、能查看反馈记录及回复结果，如APP中设置“我的反馈”、邮件回复结果；
4、附带相关信息，如token、账号信息、地区、运营商类型、 *** 作系统版本、APP版本等信息，以便更准确分析需求、定位缺陷；
5、 归类整理，反馈较多的整理成常见问题。
6、输入框过滤！@~#￥%……&*等特殊字符，以防SQL注入，建议设置每天提交次数限制机制，以防止机器提交垃圾数据。
7、有些APP，意见反馈入口会放在主界面，或新版初装二次启动时引导用户反馈（吐槽）。这些都是为了得到更多反馈，优化完善产品。
#本文同步发布到 pm263.com ，pm263为你提供更多更全的产品经理干货，欢迎大家访问。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）