다음을 통해 공유

ORMs and changing data stores

  • 아티클

The folks at Rails Envy have posted a bunch of funny parodies of the "Mac vs PC" pitting ROR versus various technologies.

The one to pay particular attention to is ad #4 out of 4:  Changing Databases.

Cleverly done - but for anyone that knows what it is like to change the DBMS for an existing app, this sort of claim is a gross exaggeration.

Changing backends for a non-trivial app is much more than just changing the connection information in the config file.   Assuming that the underlying providers completely abstracts the differences between data stores (different semantics, DBMS specific datatypes, unsupported features, etc) - of which I am very doubtful, there is still the question of performance and scalability characteristics (and most likely issues) of the data stores to think about.  At a bare minimum, I think changing the data store means a round of testing and performance/ scalability tuning - and hence probably changing some parts of the app's code and design.    This all comes back to my first rule of ORM technologies:

The boundary between the app and the data store, although abstracted in code/ design by the ORM should be explicit and should never be treated in a completely transparent manner.

Rails does some very nice things, and I buy that the Rails developer will have to change less app code (most ORM’s support this) however I am very skeptical it makes the backend store completely transparent to the app. I am also very skeptical the Rails developer in the video ever makes it to the beach because I am pretty sure the client calls him about some “scary perf issues” they are seeing with the new DBMS.

Comments