外键在电商网站数据库设计中用的多不多啊？

外键在电商网站数据库设计中用的多不多啊？

比如用在一些关联表上，感觉很实用，保证了不会产生错误的数据行，和无用的数据行，但是也有人说尽量不要去使用外键，在程序中控制数据的完整性约束性就可以了，否则不方便维护，我也不知道到底怎么样好。

回复内容：

外键在电商网站数据库设计中用的多不多啊？

比如用在一些关联表上，感觉很实用，保证了不会产生错误的数据行，和无用的数据行，但是也有人说尽量不要去使用外键，在程序中控制数据的完整性约束性就可以了，否则不方便维护，我也不知道到底怎么样好。

但是也有人说尽量不要去使用外键，在程序中控制数据的完整性约束性就可以了，否则不方便维护
你要看是什么人说的。
很多程序员的数据库水平比不上用户。这些人认为程序是万能的。
很多DBA认为数据是最重要的，比程序活的长。程序不能用了，数据仍是企业的重要资产。

如果不用外键，数据的完整性得不到保证。如果你觉得这样可以接受，当然可以不用外键。
外键是基本的数据库约束，如果这都省略了，那你的数据库根本不能称为数据库。很多人说关系数据库性能差，其实大部分都是他们设计得差。

下面谈谈很多人所说的外键的缺点。
外键会带来不便

1. 比如，删一条数据出错
   我觉得这不是坏事，尤其是对用户来说。想想编程时，编译器也会报错，我们都知道这不是坏事，反而提前防止了错误。

2. 又比如，批量insert
   如果你可以肯定数据没问题，DBMS提供了忽略外键约束的选择。但是，当数据的输入来源不可靠时，很容易出现数据不一致，所以大部分时间外键（还有其他约束）是必要的。

外键需要额外的开销，降低性能
任何代码都有开销，关键看值不值得。什么事都不做，是最快的，根本不需要花时间。
正因为数据的正确性是至关重要的，用外键当然值得。

即使不用外键，你也要在程序中控制数据的正确性。所以这个开销是必须的，不能省掉的。
通过程序控制数据完整性有很多缺点，比如
1 程序bug
基本上没有无bug的程序，这就是说，外键的功能无法可靠地被程序替代。

2 数据和程序的强耦合
数据库只能被一个程序使用，要支持多个程序，并且保证数据完整性，
a) 要么重复逻辑
每个程序自己控制数据的一致性，显然是很糟糕的。
b) 要么通过共同的接口访问数据库
这是比较流行的一种方法。3层架构，SOA，...
我不敢说这些架构都是错误的，他们都有特定的用途。但是你要明白，一个系统越复杂，零件越多，出错的可能性就越大，而且性能也越差。

总而言之，如果你认为数据正确性是必须要保证的，那么你就必须付出一定的代价来实现。用外键比用程序控制更可靠，同时更简单直接，减轻了程序的负担。
DBMS有40年的历史，是顶尖的程序员用C/C++开发出来的，经过重重测试，被无数项目用到，其可靠性和性能已经接近最优状态了。
你如果觉得你们项目里的程序员能做得更好，对事务、并发等技术都无比熟悉，又有充足的时间，那你们可以用程序控制。

老实说，我接触的项目很多都是不用外键约束的，很多都是不考虑规范化设计的。这样的系统很复杂（没必要这么复杂），性能不好。这是我的切身体会。

当然，所有事情都不能一概而论，不用外键的程序也能做得很好，卖得很好。当你做决定时，要想清楚后果。
我个人倾向于经典的方法，可靠的方法。

外键能保证数据的完整性和一致性,举例说:
一个商品订单表,订单详情表,订单详情表的订单id依赖于订单表的id,
学生表,学生成绩表,成绩表中的学号依赖于学生表中的主键。

换言之,要订单详情表中的订单id要在订单表存在才能插入,成绩表中的学号要存在这个学号才能插入.

麻烦是当删除学生时要相应删除其有依赖关系的数据,

且mysql的myisam不支持外键,[设置了也无效]

看情况和偏好。有些外键可以放开，就比较灵活一点，放到程序里头去维护。