标签：数据库 foreign key
这一部分主要讲两部分内容，第一部分就是程序员使用外键和不使用外键的原因；第二部分则是进一步的原因分析
you won‘t get Orphaned Rows
you can get nice "on delete cascade" behavior, automatically cleaning up tables
knowing about the relationships between tables in the database helps the Optimizer plan your queries for most efficient execution, since it is able to get better estimates on join cardinality.
FKs give a pretty big hint on what statistics are most important to collect on the database, which in turn leads to better performance
they enable all kinds of auto-generated support -- ORMs can generate themselves, visualization tools will be able to create nice schema layouts for you, etc
someone new to the project will get into the flow of things faster since otherwise implicit relationships are explicitly documented
you are making the DB work extra on every CRUD operation because it has to check FK consistency. This can be a big cost if you have a lot of churn
by enforcing relationships, FKs specify an order in which you have to add/delete things,which can lead to refusal by the DB to do what you want. (Granted, in such cases, what you are trying to do is create an Orphaned Row, and that‘s not usually a good thing). This is especially painful when you are doing large batch updates, and you load up one table before another, with the second table creating consistent state (but should you be doing that sort of thing if there is a possibility that the second load fails and your database is now inconsistent?).
sometimes you know beforehand your data is going to be dirty, you accept that, and you want the DB to accept it
you are just being lazy :-)
If you are using a relational database then it seems you ought to have somere lationships defined in it. Unfortunately this attitude (you don‘t need foreign keys) seems to be embraced by a lot of application developers who would rather not be bothered with silly things like data integrity (but need to because their companies don‘t have dedicated database developers). Usually in databases put together by these types you are lucky just to have primary keys;)
或许也是“教养”的问题
This is an issue of upbringing. If somewhere in your educational or professional career you spent time feeding and caring for databases (or worked closely with talented folks who did), then the fundamental tenets of entities and relationships are well-ingrained in your thought process. Among those rudiments is how/when/why to specify keys in your database (primary, foreign and perhaps alternate). It‘s second nature.
If,however, you‘ve not had such a thorough or positive experience in your past with RDBMS-related endeavors, then you‘ve likely not been exposed to such information. Or perhaps your past includes immersion in an environment that was vociferously anti-database (e.g., "those DBAs are idiots - we few, we chosen few java/c# code slingers will save the day"), in which case you might be vehemently opposed to the arcane babblings of some dweeb telling you that FKs (and the constraints they can imply) really are important if you‘d just listen.
Most everyone was taught when they were kids that brushing your teeth was important. Can you get by without it? Sure, but somewhere down the line you‘ll have less teeth available than you could have if you had brushed after every meal. If moms and dads were responsible enough to cover database design as well as oral hygiene, we wouldn‘t be having this conversation. :-)
I‘m going to use the distilled "foreign keys are like brushing your teeth: go ahead, do without it, but careful when you smile" – Mark Sowul
I believe that the real reason FKs constraints are not used by some (most, from my perspective) is sheer laziness under the pretense that they can defend their laziness with their performance savings argument. I firmly believe that the vast majority of the Stupidity Expense our company incurs is due to lack enforcement of FK constraints and the ripple effect that this has through acompany. Lack of Unique Keys is the other thing that drives me nuts next to 2000+ line stored procedures with 12 levels of nested IFs and random indenting,but I‘ll stop now. – ChadD
在数据库的设计中，外键（Foreign key）约束是否真的有必要呢？（二）
标签：数据库 foreign key
原文地址：http://lsieun.blog.51cto.com/9210464/1676569
