c# print document barcode Legacy databases and custom SQL in Java

Maker QR in Java Legacy databases and custom SQL

Legacy database integration and tricky mappings Customization of SQL statements Improving the SQL schema with custom DDL

Many examples presented in this chapter are about difficult mappings. The first time you ll likely have problems creating a mapping is with a legacy database schema that can t be modified. We discuss typical issues you encounter in such a scenario and how you can bend and twist your mapping metadata instead of changing your application or database schema. We also show you how you can override the SQL Hibernate generates automatically. This includes SQL queries, DML (create, update, delete) operations, as well as Hibernate s automatic DDL-generation feature. You ll see how to map stored procedures and user-defined SQL functions, and how to apply the right integrity rules in your database schema. This section will be especially useful if your DBA needs full control (or if you re a DBA and want to optimize Hibernate at the SQL level). As you can see, the topics in this chapter are diverse; you don t have to read them all at once. You can consider a large part of this chapter to be reference material and come back when you face a particular issue.

In this section, we hope to cover all the things you may encounter when you have to deal with an existing legacy database or (and this is often synonymous) a weird or broken schema. If your development process is top-down, however, you may want to skip this section. Furthermore, we recommend that you first read all chapters about class, collection, and association mappings before you attempt to reverse-engineer a complex legacy schema. We have to warn you: When your application inherits an existing legacy database schema, you should usually make as few changes to the existing schema as possible. Every change that you make to the schema could break other existing applications that access the database. Possibly expensive migration of existing data is also something you need to evaluate. In general, it isn t possible to build a new application and make no changes to the existing data model a new application usually means additional business requirements that naturally require evolution of the database schema. We ll therefore consider two types of problems: problems that relate to the changing business requirements (which generally can t be solved without schema changes) and problems that relate only to how you wish to represent the same business problem in your new application (these can usually, but not always, be solved without database schema changes). It should be clear that the first kind of problem is usually visible by looking at just the logical data model. The second

more often relates to the implementation of the logical data model as a physical database schema. If you accept this observation, you ll see that the kinds of problems that require schema changes are those that necessitate addition of new entities, refactoring of existing entities, addition of new attributes to existing entities, and modification to the associations between entities. The problems that can be solved without schema changes usually involve inconvenient table or column definitions for a particular entity. In this section, we ll concentrate on these kinds of problems. We assume that you ve tried to reverse-engineer your existing schema with the Hibernate toolset, as described in chapter 2, section 2.3, Reverse engineering a legacy database. The concepts and solutions discussed in the following sections assume that you have basic object/relational mapping in place and that you need to make additional changes to get it working. Alternatively, you can try to write the mapping completely by hand without the reverse-engineering tools. Let s start with the most obvious problem: legacy primary keys.