I would not use a separate table because that would have all sorts of crazy impacts on reporting and such. However, you could add a addressType field to the Address table that would be set to mailing, shipping, invoice mailing, etc. You could easily write a business rule that states that if the type is set to "Invoice Mailing" or "Invoice Shipping" then it cannot be modified.
Keep in mind that the idea that these are duplicates is really just a human concept. As far as the business rule and the code is concerned they are completely different addresses. The fact that their various attributes are the same as another address's attributes is simply a coincidence **at this point in time** and may not stay that way. On top of all this, another thing you should think about is if it is: Invoice <<-> Address or InvoiceItem <<-> Address. Can individual items be invoiced or shipped to different addresses? Should this relationship be: InvoiceItem <->> InvoiceItemAddress <<-> Address and InvoiceItemAddress has a Type attribute that would allow you to set if it is the invoice or shipping or both. Or the mailing address may be related to the Invoice, but the shipping address is related to the InvoiceItem. This is getting really complicated, and is quite likely more complicated than it needs to be, depending upon your business requirements. But the business requirements are the key. No matter how cool or efficient your code is, it must do what the business rules require. I think this is a case of needing more clearly defined requirements from your business users. Once you have exactly what the requirements are it will be easier to say exactly how the DB and EOs should be structured. Questions to ask your business users: 1) Is it possible that items on an invoice will be shipped to two different addresses 2) Is it possible that one item on the invoice will be shipped to two different addresses 3) If a customer's address changes, should it have any impact on the addresses of historical orders, invoices, etc. Keep in mind that the people that should answer this question may not be the ones actually using the app. It may be the decision of the Chief Financial Officer or Comptroller as to what data must be tracked for historical purposes, but it may be a staff accountant that actually uses the app. Good luck. I think this is the fun part of writing an app! Dave On Nov 16, 2009, at 9:26 AM, Gustavo Pizano wrote: > Hello. > > Aha, i see, what about instead of having a single Address table with > duplicates, I have 2 Address table, one for the person and one for the > invoice, let's called InvoicedAddress, so when creating the invoice, I as you > say, make a copy of the selected User address and assign it to > InovoicedAddress instead? this will create the record on that table when > saveChanges(); isn't it? > > G. > > > On Nov 16, 2009, at 3:20 PM, David Avendasora wrote: > >> Hi Gustavo, >> >> This is one of those situations where the business rules contradict >> Normalization rules for the DB. >> >> The Business rules override the normalization rules. >> >> Invoice should have it's own relationship to Address, and it should not >> point to the same object as the person does. When you create an invoce and >> give it an address, you should duplicate the person's address object and >> then add the duplicate to the Invoce. You will end up with multiple copies >> of the same address in the DB, but if the Invoice must maintain the address >> without changes, you can't relate it to the same object. >> >> Duplicating EOs is simple using the method outlined in Practical WO, and I >> think the copyable interface described there has been added to >> ERXGenericRecord so you should be able to do this with very little work. >> >> Having multiple instances of the same object is usually a no-no from both >> the WO and DB perspective, but in the situation you describe, duplicate >> instances _is_ the way to go, because they are only duplicates by >> coincidence, not by business rule. >> >> Dave >> >> >> On Nov 16, 2009, at 6:22 AM, Gustavo Pizano wrote: >> >>> Hello all. >>> >>> I know this is off topic, but you guys have helped me in the past with such >>> a questions, so I hope Im not bothering anybody. >>> >>> Im building a Invoicing app, so I have my EOModel and this is what I have. >>> >>> Person: >>> Client: Parent is Person >>> User: Parent is Person. >>> >>> Person < >> Address (toAddress) >>> >>> Invoice << > User (toUser) >>> Invoice<< > Client (toClient) >>> InvoiceItem<< >> Invoice >>> InvoiceStatus< >> Invoice >>> >>> now... what happens if the Person changes address?, it will change the >>> address of all already created invoices, which for record purposes its not >>> allowed, it think. (I mean my already created invoices should stay as they >>> where created) >>> >>> So is it correct to add a relation from Invoice << > Address ?, so when I >>> add a new address to Person the invoice will kept the old address. right? >>> >>> how can I avoid when modifying the address, if I do this, then the invoice >>> toAddress will change also. >>> >>> Thanks >>> >>> >>> G. _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com >>> >>> This email sent to [email protected] >>> >>> >> >> David Avendasora >> Senior Software Engineer >> K12, Inc. >> >> ***** >> WebObjects Documentation Wiki : >> http://wiki.objectstyle.org/confluence/display/WO/ >> ***** >> WebObjects API: >> http://developer.apple.com/legacy/mac/library/documentation/MacOSXServer/Reference/WO54_Reference/index.html >> ***** >> > > > David Avendasora Senior Software Engineer K12, Inc. ***** WebObjects Documentation Wiki : http://wiki.objectstyle.org/confluence/display/WO/ ***** WebObjects API: http://developer.apple.com/legacy/mac/library/documentation/MacOSXServer/Reference/WO54_Reference/index.html ***** _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
