• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Is it a bad practice to put all addresses into one table?

 
Ivan Jouikov
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Say I have 2 objects: Client and Supplier.

Both have billing and shipping addresses. I COULD make 2 tables, ClientAddresses and SupplierAddresses and reference the parent with a ParentID, or I could make one table - Addresses, and reference the child with an AddressID.

Which was is better and why?
 
stu derby
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ivan Jouikov:
Say I have 2 objects: Client and Supplier.



And you're not going to have an Address object? Why not? Are you going to essentially identical methods for dealing with a Client's address and a Supplier's address? Bad design...

And once you realize that you should have an Address object, doesn't your question answer itself?

And of course, what are you going to do when you have a someone who is both a Client and a Supplier? Maintain 2 addresses for one entity? I can hear the phone call now... "Hello? I asked you to change our mailing address last week!" "We did..." "Then how come..."....
[ May 30, 2006: Message edited by: stu derby ]
 
Ivan Jouikov
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Err I meant we have these 2 objects.

Should we now have 2 more objects, ClientAddress and SupplierAddress (which keeps our tables neat and clean and minimal performance gain) or just an Address?

It's just that, what happens if all clients addresses need to have an "Mr./Mr.s" field? Or something like that.

I guess you're saying I should go with just one Address, anyone second that?
 
Michael Valentino
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You could do it that way, or you could make an abstract class Address with basic info that all addresses have and make two concrete subclasses that have client specific info added to it and supplier specific info added to it. example:



Then for your Client and Supplier, you'd have an address property of type Address. This is basic OO.

As for the database side of things your ADDRESS table could include fields that pertain to all addresses making some fields optional. That way the Client can maintain fields pertaining only to clients, and Suppliers can maintain fields pertaining only to suppliers. You could argue that this might be a waste of space (the optional fields) but so would be maintaining two seprate tables of basically the same type of info.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35279
384
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ivan,
If there is no difference between a SupplierAddress and ClientAddress, you could only have one Address class. The Supplier and Client objects could each contain a field for an Address object. (As sson as I typed this I realized it was what Michael said.)

I guess you're saying I should go with just one Address, anyone second that?

I second (or third) that. An address is an address.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic