WHat is the best practice way to handle the following situation?

I have an Address object with properties:
Street
City
State

In my model I have unrelated entity classes
foo.Vendor,
foo.Customer,
foo.Client,
foo.Warehouse
all of which need a collection of address components.

Is is better to have multiple address tables, i.e
VendorAddress, CustomerAddress etc.

or should I make one table with multiple (nullable) id columns
vendorId
customerId
clientId
warehouseId
Street
City
State

or is there another way (via a bridge table or something)?
Is the second option above even possible with Hibernate?

Thanks for any help.

You could use Hibernate's component mapping (see ch 7 sec 7.1. Dependent objects of the docs). At the database side of things, this would give each of your tables the 3 columns Street, City and State and in the Java space you would have a reusable Address object that is linked to your primary classes by composition.

This may not be what you want but is one way to map the attributes.

Rather than thinking about the best way to map entities in the database space I find it's better to design your Java classes so that they solve your business problem and them make the mappings work for the Java design.

Hope this helps.

Nick

I have already settled on having a reusable Address object.
The question is about how to persist those addresses.

It is not a matter of merely using extra columns, because I want to keep a LIST of addresses for each object.

The component approach suggested would result in the following 8 tables:
Vendor
VendorAddresses
Customer
CustomerAddresses
Client
ClientAddresses
Warehouse
WarehouseAddresses

What I was wondering is if there was a way to do this with 5 tables:
Vendor
Customer
Client
Warehouse
All_The_Addresses

And I was wondering which might be more efficient, from a performance point of view.
In reality my object model is very fine-grained, with each object having multiple collection properties, and I am wondering if behind the scenes it is going to result in massive table-joins.

I must admit to not being a database expert, but I am hoping to learn a little more as I go.

I think you have mis-understood my sugestion.

The component approach does not create those extra tables. If you have a look at 7.1 in the doc's and try it, it adds columns to each table - de-normalising the address class into each table.

You're thinking about a <composite-element> which is a collection of components which would create extra tables.

Here's the text from the doc's...

Our Hibernate mapping would look like:

<class name="eg.Person" table="person">
<id name="Key" column="pid" type="string">
<generator class="uuid.hex"/>
</id>
<property name="birthday" type="date"/>
<component name="Name" class="eg.Name"> <!-- class attribute optional -->
<property name="initial"/>
<property name="first"/>
<property name="last"/>
</component>
</class>
The person table would have the columns pid, birthday, initial, first and last.

Have a look at this link too http://www.xylax.net/hibernate/index.html section 11.

Cheers,

Nick