复杂和遗留的数据库schema
本文作者：苏生米沿
本文地址：http://blog.csdn.net/sushengmiyan/article/details/50414652
In this chapter, we focus on the most important part of your system: the databaseschema, where your collection of integrity rules resides—the model of the realworld that you’ve created.
If your application can auction an item only once in the real world, your database schema should guarantee that. If an auction always has a starting price, your database model should include an appropriate constraint.
If data satisfies all integrity rules, the data is consistent, a term you’ll meet again in section11.1.
We also assume that consistent data is correct: everything the database states, either explicitly or implicitly, is true; everything else is false.
If you want to know more aboutthe theory behind this approach, look up the closed-world assumption (CWA).
本章，我们主要集中在你系统中最重要的部分，数据库schema，你的完整性规则驻留的地方---你创建的真实世界的模型。如果在真实世界中你的应用程序只能对一件物品竞价一次，你的数据库schema就应保证这点。如果一个竞拍总有一个开始价格，你的数据库模型应该包括一个适当的约束。如果数据满足所有完整性约束，数据就是一致的，这个术语会在11.1章节再次遇到。
我们还假设一致的数据是正确的，数据库所表述的所有数据，无论是显式的还是隐式的，都是正确的，其它的所有都是错误的。如果你想知道这个理论背后的更多知识，请参考封闭世界假设说（CWA）。
Major new features in JPA 2
Schema generation and execution of custom SQL scripts during bootstrap is now standardized and can be configured on a persistence unit.
You can map and customize schema artifacts such as indexes and foreign key names with standard annotations.
You can map foreign keys/many-to-one associations in composite primary keys with @MapsId as “derived identity.”
JPA2的新特性
在启动的时候生成schema和执行自定义的SQL脚本现在已经标准化了，在持久化单元中就可以进行配置了。
你可以映射和自定义schema物件，像索引和外键，使用标准的注解名称。
你可以映射外键、多对一关系，通过使用@mapsid来定义复合主键这样的衍生主键。
Sometimes you can start a project top-down. There is no existing database schema and maybe not even any data—your application is completely new.Many developers like to let Hibernate automatically generate the scripts for a database schema. You’ll probably
also let Hibernate deploy the schema on the test database on your development machine or your continuous build systems for integration testing.
Later, a DBA will take the generated scripts and write an improved and final schema for production deployment.
The first part of this chapter shows you how to improve the schema from within JPA and Hibernate, to make your DBA happy.
At the other end of the spectrum are systems with existing, possibly complex schemas, with years’ worth of data. Your new application is just a small gear in a big machine, and your DBA won’t allow any (sometimes even non-disruptive) changes to the database.
You need a flexible object/relational mapping so you don’t have to twist and bend the Java classes too much when things don’t fit right away.
This will be the subject of the second half of this chapter, including a discussion of composite primary and foreign keys.
有时候，你可以自顶向下的开始一个工程。你的项目工程是全新的，没有现存的数据库shema甚至没有数据。很多开发者喜欢让hibernate来产生数据库的schema的脚本。你可能让hibernate部署你的测试库在你的开发机器上，或者你的集成测试中。稍晚些，DBA就会拿到生成的脚本，改善一下并且写出改善之后的最终产品发布schema。本章的第一部分就给你展示如何提升hibernate和JPA生成的schema,来让你的DBA高兴。
在光谱的另一端就是集成可能是复杂的schema的具有多年数据价值的系统了。
你的新应用就是一个在大机器上的小齿轮。你的DBA不会允许你进行任何的数据库改变（甚至包括非破坏性的）。你需要一个灵活的对象/关系映射，那样的话，你就不需要为不合时宜的事情扭曲或者弯曲你的java实现类，这是本章第二部分的主题，包括讨论一个复合主键和外键。
摘自 hibernate与JPA 第九章。转载请标明来源，谢谢。
