讨论关于数据库到底要不要建立主外键关系？
这个问题一直困扰着我，希望大家结合自己工作经验，与我和类似网友遇到些问题给分享一下？

------解决方案--------------------
看具体业务关系呀
------解决方案--------------------

探讨

这个问题一直困扰着我，希望大家结合自己工作经验，与我和类似网友遇到些问题给分享一下？

------解决方案--------------------
主键一般是要建立的，外键不必要的时候就不用建立。
------解决方案--------------------
看具体业务逻辑吧
两张表一般如果要保持数据的一致性还是建议用主外键去约束
比如更新 删除 两个表同步
当然这样也可以通过触发器去实现
但一般坚持 能用约束实现的尽量不用触发器
------解决方案--------------------
一般而言，一个实体不能既无主键又无外键。在E－R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定
义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。 

　　主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数
据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映
了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实
体之间的连接。
------解决方案--------------------
一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组合
主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间；
------解决方案--------------------
就我个人而言，我做“项目”的时候很少建立主外键的，感觉那样做有点麻烦，而且如果数据库数据表比较多的时候，容易造成混乱！不利于嵌套SQL的语言编程，对于主外键的处理大部分是在嵌套SQL的语言中进行的..

但是又觉得既然数据库领域涉及到了主外键这么个说法，肯定有他有的用途！可能是我做的“项目”比较简单，还没有体会到吧！

等待高人...
------解决方案--------------------

探讨

一般而言，一个实体不能既无主键又无外键。在E－R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定
义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。

　　主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数
据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映
了他对信息系统核心(数据……

------解决方案--------------------
本人做的CRM中是没有这个东西的，曾经有一个客户的IT部门的一个负责人还对这个有偏见，其实有或者没有都行，我们的是在程序中进行控制的。控制得好耶能保证系统能正常运行。
------解决方案--------------------
开发测试的时候建，等到正式上线就去掉。
------解决方案--------------------
理论联系实际
------解决方案--------------------
外键还是很有必要的。
------解决方案--------------------
主键通常必须有。
外键尽量有。

完整性约束定义了数据库的边界，从语义上防止脏数据的产生。业务系统开发时固然可以用存储过程保证逻辑的完整性，但因为表上没有约束，只要存在越过存储过程直接访问表的可能，表中就有可能出现脏数据。

此外，定义好的约束还能起来“自文档”的作用。一看表结构，基本就知道业务逻辑是怎么样的。

------解决方案--------------------
本人理解：

1.如遵循书本或者按着ER设计规范，主外键设计是很有必要的，尤其是一般小系统的设计这样很有必要，逻辑很清晰

2.如是商业开发，更多的一致性和关联都会交给程序业务层处理，程序本身对数据一致性进行维护，所以，很多商业数据库中很少地方采用主外键约束，何况业务越复杂，主外键约束很是复杂，因此不适于主外键直接约束