Thanks Dave you always so helpful, :D:D:D.
I was thinking this morning in this approach to set in the Invoice table the
address information, so there is no duplicity in the Address Table, but as you
say, "Now this looks absolutely horrible from a DBA's standpoint,.", thats why
I didn't gave it more thoughts.
Ok so now I have 2 ways to solve this... Im gonna "think it with the pillow "
and tomorrow start implementing.
once again thanks.
G.
On Nov 16, 2009, at 5:28 PM, David Avendasora wrote:
>
> On Nov 16, 2009, at 11:14 AM, David Avendasora wrote:
>
>>
>> On Nov 16, 2009, at 10:36 AM, Gustavo Pizano wrote:
>>
>>> Ok he isn't in the office. but the other person told me that for point No
>>> 3. bellow, it should not happen, because if the tax office were to compare
>>> the invoicing company (user) and the invoiced client (client), the
>>> invoices shall be exactly the same. So historical data should not have
>>> impact.
>>
>> I'm not sure understand. You are saying that you need to maintain a
>> "snapshot" of the Invoice as it existed when sent to the customer, so the
>> customer's version of the invoice must match exactly your "snapshot" of the
>> invoice, right?
>>
>>> So now thinking a little bit more,
>>> If I add a type attribute for "Shipping address, Billing Address" and also
>>> have a status attribute like "Active, Non Active", so in case the Billing
>>> or shipping addresses changes, I change the status also, so then when
>>> creating new invoices I will set it to the Active Billing Address and
>>> Shipping address of the User. and the old addresses will remain in the
>>> table, o the historical Invoices will still point to that one.
>>
>> Yes, this would work, and cut down on the duplicates in the database but is
>> a lot more complicated logic than simply _always_ duplicating the address
>> object when assigning it to an invoice. You can even just override the
>> setter for the relationship on the Invoice class like so:
>>
>> public void setMailingAddress(Address newMailingAddress) {
>> super.setMailingAddress(newMailingAddress.copy());
>> }
>>
>> How expensive are additional address rows for the DB? This solution is dead
>> simple and you don't have to keep track of an address's status. Remember,
>> convoluted logic that is hard to maintain can be far worse down the road
>> than some extra data in a database table. Especially in this situation.
>>
>> Also, imagine the situation where the address changes, then changes back
>> (which could happen), you would still most likely end up with two addresses
>> in the DB that are identical, unless the user realizes that it isn't a new
>> address and reactivates the previously used one, or you write the logic to
>> capture that situation and handle it.
>>
>> Since I do not think you can eliminate duplicates, even with more
>> complicated logic, I don't see the value in trying. You will always have to
>> assume that there are duplicate addresses in the DB and have to write logic
>> to handle it.
>
> You know, now that we've come this far to always using a copy of the address,
> you could just embed it in the Invoice itself by adding fields to the
> Invoice's table. This would be even less "logic". You could even have a cover
> method such as:
>
> public void setMailingAddress(Address mailingAddress) {
> setStreet1(mailingAddress.street1());
> setCity(mailingAddress.city());
> ...
> }
>
> Now this looks absolutely horrible from a DBA's standpoint, but from a
> data-integrity standpoint, it is much more secure.
>
> I love a well-nomralized database that has no duplicate information, but if
> you want to be absolutely sure that things can not be accidentally changed,
> this is the probably the best way to assure that.
>
> Dave
>
>
>>
>> Dave
>>
>>
>>>
>>> What you think?
>>>
>>> G.
>>>
>>>
>>>>
>>>>
>>>>> 2) Is it possible that one item on the invoice will be shipped to two
>>>>> different addresses
>>>> Nop, the invoice will be shipped all in one to the same place, in case
>>>> they need to ship to another place they need to create a different invoice.
>>>
>>> Here I made mistake, an Invoice and all its item can be shipped to one
>>> place only, if one of the items needs to be shipped to another location,
>>> then it must be another invoice.
>>>
>>>
>>>>
>>>>> 3) If a customer's address changes, should it have any impact on the
>>>>> addresses of historical orders, invoices, etc.
>>>> This is the main question.. I will have to ask the accountant to see what
>>>> he thinks.
>>>>
>>>>>
>>>>> 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!
>>>>>
>>>> Yeeah yeah, lifting req can be sometimes a PITA.
>>>> G.
>>>>
>>>>
>>>>> 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 (Webobjects-dev@lists.apple.com)
>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
>>>>>>>>
>>>>>>>> This email sent to webobje...@avendasora.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>> *****
>>>>>
>>>>
>>>
>>
>> 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 (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
>>
>> This email sent to webobje...@avendasora.com
>
> 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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
