ORM is about mapping two different worlds, both with their own paradigm, their own way of doing things, their own rules. In your domain model you have objects (entities) with properties. In the relational database you have tables, with columns. In the relational world tables are 'normalised'. The First Normal Form says: only atomic fields. So: no collection in a field, but couple tables with foreign keys. That rule does not exist in the object world: an addresses-field can have (a collection of) multiple addresses. To connect those two worlds we have to MAP the objects and the tables: Object Relational Mapping.
It is a mistake I see very often when people start using an ORM (and a big part of the questions on this mailing list): that they keep thinking in a relational paradigm while working in the object world. You have to switch that button, forget about foreign keys and normalisation and build a good model with your objects. Doesn't matter if the data in the database is from some legacy application, made in another era, while we were all first making a data-model with ERP-diagrams and procedural code. Using an ORM is a next step. You can now make a good model, one you could even explain to non-tec hnical stakeholders (end users). Just map the brand new model to the old database. This is good news: forget about the database for a moment and *start thinking in objects*. -- You received this message because you are subscribed to the Google Groups "doctrine-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/doctrine-user. For more options, visit https://groups.google.com/groups/opt_out.
