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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 我有个秒级任务 怎么处理 linux 的crond服务 最少是1分钟 php
  • 后端thinkphp和前端vue怎么协调
  • php类 方法里调用curl(),不成功
  • symfony第三方登录
  • Laravel 对登录有一些问题
  • 移动端页面中添加二维码图片,为什么有的浏览器无法识别?
  • 微信扫码的问题
  • PHP中,把$_SERVER[‘QUERY_STRING’]转换为$_GET数组
  • 如何获取字符串中的内容?
  • mysql,表设计
  • php正则匹配内容?