On ColdFusion ORM and DBAs

June 22, 2009 · 8 Comments

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.

Tags: ColdFusion · Centaur

8 response s so far ↓

1 Brian Swartzfager // Jun 22, 2009 at 8:08 PM

I'm a bit puzzled by the end of the post: why would I need to convince my DBAs that Hibernate is a good thing? Normally, I just ask them to create the tablespace I need and give me the information needed to set up the datasource on ColdFusion: would I need anything additional from them to use Hibernate?
2 Sean Corfield // Jun 22, 2009 at 8:28 PM

I suspect the "My DBA isn't going to like that!" comments come more from CFers than actual DBAs. Whilst some DBAs do have a bit of an axe to grind with Hibernate, in general I've found them to be reasonably happy to work with what Hibernate creates and do the analysis and tuning that they'd do with any DB created by someone outside their team.

Of course, if you have the sort of DBA that doesn't let you so much as alter the length of an existing column, you're going to run into a lot of resistance to the idea of software that automatically generates the entire schema for you :)

I hope that CF-ORM means more people will start their design with objects and relationships and let Hibernate take care of creating and maintaining the schema so that we can get better designed applications (model-focused, instead of database-focused).

It'll be very interesting to see how CF-ORM is received in the wild (I'm already sold on Hibernate having used it with Groovy at Broadchoice!).
3 Andrew Scott // Jun 23, 2009 at 1:16 AM

There is also the other side of the coin with Hibernate as well. And that is that one can use what is called legacy databases with Hibernate. That coupled with the mapping can still give the best of both worlds, I don't see DBA's having to much of a complaint as Sean has stated most that I have worked with are more than happy to work with hibernate.
4 Chris Hayes // Jun 23, 2009 at 2:05 AM

I for one welcome our new ORM overlords.

In all seriousness this is yet another positive abstraction layer that will make an application more portable over time. Hibernate is proven technology and let's face it there are an awful lot of apps out there with poorly written SQL that an ORM system would have helped avoid. Best practices are still necessary however this will make life easier for many and hopefully drive people further down the wonderful road of abstracted objects with well defined relationships.
5 Jake Munson // Jun 23, 2009 at 10:46 PM

I think Sean got it right...it depends on the DBA. If your DBA is very protective of his database, they are not going to like you using a code that creates SQL on the fly.

Put yourself in their shoes. What if a graphic designer were to come to you and say, "Hey CFer...I've got this tool that generates CF code to support my designs...you can just plug this code into your server and you won't have to do anything else!" Would you be very happy about this? Wouldn't you be a little skeptical about this auto-generated CF code?
6 Ben Shichman // Jul 6, 2009 at 1:46 PM

Having just completed a massive Java based project using Hibernate, I would say it is far from a panacea. If you are working with complex and large datasets (meaning hundreds of thousands to millions of rows) then Hibernate can actually bog you down when it is constructing the datasets for your queries. We are looking at removing Hibernate from this application and writing the queries directly to the JDBC driver. Hibernate is great, but seems best suited to smaller sizes of data.
7 catering company raleigh // Jan 20, 2010 at 8:15 AM

You seem to have got the niche from the root, Awesome work

Regards
8 MeganF1ch // Jan 25, 2010 at 7:34 PM

Strong time. , replacing lawnmower blade, buy men's shirts, new mens shirts, blade cut off, stripe button down shirt, buy personalized t shirts, floral mens shirt, tee shirt printing, blade z xtr 250, white and orange shirt, shirt by shirt clothing,

Blog