For me it works best to *model first* and only later look at tables and mapping. To model is to define use cases and the objects that interact in that. In your specific case something with products, orders, invoices and payments, some of which are "recurring". Your story about that is not yet clear and sound. If that modeling part is OK, then mapping to tables is no problem. You can see it as an indication that your model is not yet good when you have mapping problems. However: building a good model is not the subject of this mailing list (and might take a few years practice). It is not something to solve in a few lines in a mailinglist either. It is very domain specific. It deserves careful analysis, sessions with your domain-experts time and several iterations. Talking about iterations: first implement a simple, but working and useful model and then add more complex scenarios.
"Many to one", "many to many" etc. are terms that are only relevant for mapping between objects and tables. "Records" belong to tables. Those words are not relevant for modeling. Focus on terms thet are used in the domain you are modeling.I suppose you are not selling records or many-to-one-products, whatever that may be. On Wednesday, 23 April 2014 23:25:37 UTC+2, Parsifal wrote: > > Herman, > as you recommended I am trying to forget about tables and think about > objects, i am a bit confused about this i appreciate your clarification, > this is about relations between orders and invoices: > In shopping cart user should be able to add multiple items but finally > when order should be created, this is better to create separate record for > each order item because some items may have recurring invoices and some > items may not, or may be even some items are included for free like bonus > etc. So to manage recurring invoices better to have separate order record > for each item however all items were in one cart. But for these all order > items there should be one initial invoice on first purchase (however for > next recurring there might be separate invoice for each item) so at this > time the relation from order to invoice at first time is many to one: Some > order items have one invoice because purchased together at the same time > and payment should be done once for all items. But on recurring invoices, > the relation from order to invoice would be one to many, because order done > once and has several recurring invoices, so thinking as object the relation > between order to invoice is many to many? Right? I appreciate your advice. > -- 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/d/optout.
