https://www.yiibai.com/mysql/introduction-sql-views.html
视图
使用数据库视图的优点
数据库视图允许简化复杂查询：数据库视图由与许多基础表相关联的SQL语句定义。
您可以使用数据库视图来隐藏最终用户和外部应用程序的基础表的复杂性。
通过数据库视图，您只需使用简单的SQL语句，而不是使用具有多个连接的复杂的SQL语句。数据库视图有助于限制对特定用户的数据访问。 您可能不希望所有用户都可以查询敏感数据的子集。可以使用数据库视图将非敏感数据仅显示给特定用户组。
数据库视图提供额外的安全层。 安全是任何关系数据库管理系统的重要组成部分。 数据库视图为数据库管理系统提供了额外的安全性。
数据库视图允许您创建只读视图，以将只读数据公开给特定用户。 用户只能以只读视图检索数据，但无法更新。数据库视图启用计算列。 数据库表不应该具有计算列，但数据库视图可以这样。
假设在orderDetails表中有quantityOrder(产品的数量)和priceEach(产品的价格)列。
但是，orderDetails表没有一个列用来存储订单的每个订单项的总销售额。如果有，数据库模式不是一个好的设计。
在这种情况下，您可以创建一个名为total的计算列，该列是quantityOrder和priceEach的乘积，以表示计算结果。当您从数据库视图中查询数据时，计算列的数据将随机计算产生。数据库视图实现向后兼容。 假设你有一个中央数据库，许多应用程序正在使用它。
有一天，您决定重新设计数据库以适应新的业务需求。删除一些表并创建新的表，并且不希望更改影响其他应用程序。在这种情况下，可以创建与将要删除的旧表相同的模式的数据库视图。数据库视图的缺点
除了上面的优点，使用数据库视图有几个缺点：
性能：从数据库视图查询数据可能会很慢，特别是如果视图是基于其他视图创建的。
表依赖关系：将根据数据库的基础表创建一个视图。每当更改与其相关联的表的结构时，都必须更改视图。
https://www.yiibai.com/mysql/introduction-to-sql-stored-procedures.html
存储过程
MySQL存储过程的优点
通常存储过程有助于提高应用程序的性能。当创建，存储过程被编译之后，就存储在数据库中。 但是，MySQL实现的存储过程略有不同。
MySQL存储过程按需编译。 在编译存储过程之后，MySQL将其放入缓存中。 MySQL为每个连接维护自己的存储过程高速缓存。
如果应用程序在单个连接中多次使用存储过程，则使用编译版本，否则存储过程的工作方式类似于查询。
存储过程有助于减少应用程序和数据库服务器之间的流量，因为应用程序不必发送多个冗长的SQL语句，而只能发送存储过程的名称和参数。
存储的程序对任何应用程序都是可重用的和透明的。 存储过程将数据库接口暴露给所有应用程序，以便开发人员不必开发存储过程中已支持的功能。
存储的程序是安全的。 数据库管理员可以向访问数据库中存储过程的应用程序授予适当的权限，而不向基础数据库表提供任何权限。
除了这些优点之外，存储过程有其自身的缺点，在数据库中使用它们之前，您应该注意这些缺点。MySQL存储过程的缺点
如果使用大量存储过程，那么使用这些存储过程的每个连接的内存使用量将会大大增加。
此外，如果您在存储过程中过度使用大量逻辑操作，则CPU使用率也会增加，因为数据库服务器的设计不当于逻辑运算。
存储过程的构造使得开发具有复杂业务逻辑的存储过程变得更加困难。
很难调试存储过程。只有少数数据库管理系统允许您调试存储过程。不幸的是，MySQL不提供调试存储过程的功能。
开发和维护存储过程并不容易。开发和维护存储过程通常需要一个不是所有应用程序开发人员拥有的专业技能。这可能会导致应用程序开发和维护阶段的问题。MySQL存储过程有自己的优点和缺点。开发应用程序时，您应该决定是否应该或不应该根据业务需求使用存储过程
http://www.cnblogs.com/fuland/p/4280434.html
外键
主键和索引是不可少的，不仅可以优化数据检索速度，开发人员还省不其它的工作,
矛盾焦点：数据库设计是否需要外键。这里有两个问题：一个是如何保证数据库数据的完整性和一致性；二是第一条对性能的影响。
正方观点：
1，由数据库自身保证数据一致性，完整性，更可靠，因为程序很难100％保证数据的完整性，而用外键即使在数据库服务器当机或者出现其他问题的时候，也能够最大限度的保证数据的一致性和完整性。
eg：数据库和应用是一对多的关系，Ａ应用会维护他那部分数据的完整性，系统一变大时，增加了Ｂ应用，Ａ和Ｂ两个应用也许是不同的开发团队来做的。他们如何协调保证数据的完整性，而且一年以后如果又增加了C应用呢？
2，有主外键的数据库设计可以增加ER图的可读性，这点在数据库设计时非常重要。 3，外键在一定程度上说明的业务逻辑，会使设计周到具体全面。反方观点：
1，可以用触发器或应用程序保证数据的完整性 2，过分强调或者说使用主键／外键会平添开发难度，导致表过多等问题 3，不用外键时数据管理简单，操作方便，性能高（导入导出等操作，在insert, update, delete 数据的时候更快）
eg:在海量的数据库中想都不要去想外键，试想，一个程序每天要insert数百万条记录，当存在外键约束的时候，每次要去扫描此记录是否合格，一般还不
止一个字段有外键，这样扫描的数量是成级数的增长！我的一个程序入库在3个小时做完，如果加上外键，需要28个小时！结论： 1，在大型系统中（性能要求不高，安全要求高），使用外键；在大型系统中（性能要求高，安全自己控制），不用外键；小系统随便，最好用外键。
2，用外键要适当，不能过分追求 3，不用外键而用程序控制数据一致性和完整性时，应该写一层来保证，然后个个应用通过这个层来访问数据库。需要注意的是：MySQL允许使用外键，但是为了完整性检验的目的，在除了InnoDB表类型之外的所有表类型中都忽略了这个功能。这可能有些怪异，实际上却非常正常：对于数据库的所有外键的每次插入、更新和删除后，进行完整性检查是一个耗费时间和资源的过程，它可能影响性能，特别是当处理复杂的或者是缠绕的连接树时。因而，用户可以在表的基础上，选择适合于特定需求的最好结合。所以，如果需要更好的性能，并且不需要完整性检查，可以选择使用MyISAM表类型，如果想要在MySQL中根据参照完整性来建立表并且希望在此基础上保持良好的性能，最好选择表结构为innoDB类型
https://www.yiibai.com/mysql/sql-triggers.html
触发器
SQL触发器的优点
SQL触发器提供了检查数据完整性的替代方法。 SQL触发器可以捕获数据库层
中业务逻辑中的错误。
SQL触发器提供了运行计划任务的另一种方法。通过使用SQL触发器，您不必等待运行计划的任务，因为在对表中的数据进行更改之前或之后自动调用触发器。
SQL触发器对于审核表中数据的更改非常有用。SQL触发器的缺点
SQL触发器只能提供扩展验证，并且无法替换所有验证。一些简单的验证必须在应用层完成。
例如，您可以使用JavaScript或服务器端使用服务器端脚本语言(如JSP，PHP，ASP.NET，Perl等)来验证客户端的用户输入。
从客户端应用程序调用和执行SQL触发器不可见，因此很难弄清数据库层中发生的情况。 SQL触发器可能会增加数据库服务器的开销。
可能造成死锁