Two things come up when I talk about the upcoming ORM features in Centaur:
- DBAs are going to hate it
- It’s going to put DBAs out of work, which will make them hate it.
Let me just say, 1 may be inevitable, but 2 is quite the opposite.
To start with, there are two ways of working with ColdFusion ORM, your application, and your database:
- Start with the database and build your objects from it.
- Start with the objects and have your database built based on them.
When you start from the database and go up, if you have a bad database, there is nothing Hibernate (the underlying ORM technology in Centaur) can do to make it any better. If it is poorly indexed, or improperly normalized, the resulting objects will perform poorly, or be unnecessarily complex.
On the other hand, if you have CF go ahead and create the tables for you, you will only get the basic indices and keys needed to generate relationships: primary keys and foreign keys. You can specify indices and unique constraints, but only if you know where to put them.
In both cases you will need the skills of a DBA (either your own, or a dedicated DBAs) to help you make decisions.
What’s different then? Much like other uses of ColdFusion, it takes the knucklehead rote stuff and makes it easy.
- No building table creation scripts.
- No writing rote CRUD scripts
- DBA time can now be spent doing cool complex SQL and analysis where they really pack on the value.
How do you convince your DBAs of this? I have a few arguments:
- ColdFusion ORM uses parameterized and prepared SQL much like cfqueryparam.
- ColdFusion ORM can be configured to output generated SQL
- ColdFusion ORM is based on Hibernate, which was built keeping most database best practices in mind.
Is this going to convince every DBA? Probably not. But hopefully enough have an open mind to at least give it a shot.