2 ms·

Well, with the ORMs the objects generate the relational stuff. I enjoy modeling my entities on paper as an ERD (from the entity relationship perspective) and t

Well, with the ORMs the objects generate the relational stuff. I enjoy modeling my entities on paper as an ERD (from the entity relationship perspective) and then writing the object code. However, I have found it is sometimes necessary to denormalize my schema and store entities based on how they are presented, not necessarily the idealistic OO ORM'ed way. At the end of the day, the user doesn't care if your code is abstracted properly (who's definition?) or enough. It just needs to work speedily and correctly and be easily maintainable. I think alot of people know SQL, but may not understand how to model entities correctly, and if they can't model the entities correctly, what ever they denormalize is still coming from a 'less-good' model.

jacques_chester 16y ago
Personally, when it comes to denormalisation, my preference is that it be done in a semi-structured way such as dimensional modelling. And that's exactly what I was talking about: a key purpose for DM is to make the database more accessible for fast bulk queries at the cost of duplicate data. Whereas normalisation drives out duplication in order to maximise transactional performance and space efficiency. In your case, you start with the OLTP/normalised model, then devolve to what is actually a kind of OLAP/denormalised model. Write-oriented vs read-oriented. Maybe the missing link for relational databases in a web world is actually some kind of real-time ETL?