问题描述
有人知道论文/书籍等。数据库的文档模式？例如，一个常见的经验法则是每个表都应该有一个主键，并且该键应该是。所以我想知道有没有人写过一本书或发表关于设计关系数据库的设计模式的论文？@Gaius，
这是数据库设计者需要权衡的问题 - 数据库结构的可能稳定性是甚么？给了足够长的视野，没有什么是稳定的。或者说相反，给了足够长的地平线，一切都可以改变。代理关键（理论上）不应该改变它的意义，因为它从来没有意义开始。
我想在特定设计方案中要考虑的另一件事是谁会看到主键？如果主键是最终用户实际需要引用的，那么使它成为可以理解的东西是有意义的。但是我不能想到最终用户需要看到主键的许多情况;通常主键是存在的，以允许DB引擎加快某些操作。
我原来想到的问题是找到编码的数据库设计的设计模式通过比我自己更有经验的数据库设计师，以期希望避免一些容易避免的错误。如果有人编纂了数据库设计反模式，这将是有趣的。
具体来说，关于密钥：我非常不同意这个奇怪的想法，即密钥必须没有意义。一般来说，我认为一个数据库是事实的集合;一旦你开始添加任意数字（如生成的键）和其他不相关的信息，它应该是一个警告信号。我推荐
也许不是很像模式，但还是很好：
Stephane Faroult，Peter Robson：SQL的艺术
另一个我可以推荐的：
Vadim Tropashko：SQL设计模式 - SQL编程专家指南
关于数据建模的系统教科书：
Graeme Simsion& Graham Witt，数据建模要点
也许您实际上正在寻找风格指南？我这样的情况：
Joe Celko：SQL编程风格
Does anyone know of papers/books/etc. that document patterns for databases? For example, one common rule of thumb is that every table should have a primary key and that the key should be devoid of information content. So I was wondering if anyone had written a book or published papers regarding design patterns for designing relational databases?
@Gaius,
That is the question that a database designer needs to weigh--what is the probable stability of the database structure? Given a long-enough horizon nothing is stable. Or to say the converse, given a long-enough horizon, everything is subject to change. A surrogate key (in theory) should never change its meaning because it never had meaning to begin with.
I guess the other thing to consider in that particular design scenario is who is it that will be seeing the primary key? If the primary key is something that end-users will actually need to refer to then it makes sense to make it something they can understand. But I can't think of many cases where an end-user needs to see a primary key; usually the primary key is present to allow the DB engine to speed up certain operations.
My original thought in asking the question was to find design patterns for database design that were codified by more experienced database designers than myself so as to, hopefully, avoid some easily avoidable errors. It would be interesting reading if anyone had ever codified database design anti-patterns.
Specifically, regarding keys: I strongly disagree with the strange idea that keys must be without meaning. In general, I consider a database a collection of facts; as soon as you start adding arbitrary numbers (like generated keys) and other irrelevant information into it, it should be a warning sign. I recommend this articly by Joe Celko for more on keys.
More general notes:
Suggestions for schema designs/data models for different businesses:David C. Hay: Data Model Patterns: Conventions of ThoughtRather old, but there is a reason why it's still in print
http://www.dorsethouse.com/books/dmp.html
Maybe not very pattern-like, but still very good:Stephane Faroult, Peter Robson: The Art of SQLhttp://oreilly.com/catalog/9780596008949/
Another one which I can recommend:Vadim Tropashko: SQL Design Patterns - The Expert Guide to SQL Programminghttp://www.rampant-books.com/book_2006_1_sql_coding_styles.htm
Systematic text-book about data modelling:Graeme Simsion & Graham Witt, "Data Modeling Essentials"http://www.elsevierdirect.com/product.jsp?isbn=9780126445510
Maybe you are actually looking for a "style guide"?. I that case:Joe Celko: SQL Programming Stylehttp://www.elsevierdirect.com/product.jsp?isbn=9780120887972
这篇关于数据库模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！