My database has an organisation table and an address table. In the address table, I want to store user ID and organisation ID so that I can look these up later and also have multiple addresses for organisations or for a user to be able to select an address they have added for a different organisation. An example here would be if 2 organisations share the same property. I also want my organisation table to store the default address ID. However, this is proving awkward when using ORM Models in FuelPHP (probably irrelevant, it's just caused me to pay attention to a possible design weakness).

The above is one option, I can think of 2 more solutions. One is to have a default address table storing organisation ID and address ID, the address table can still store user and org IDs. I can then select from organisation table inner join the default address table and inner join the address ID from the address table to retrieve the address.

The second option is to have a default address field in my address table, as type bool. I then use a where statement in the elect to retrieve this address when needed.

The second option is my preferred option at the moment because it means I don't have to do too much work altering my tables and adding keys and setting relationships in my PHP framework ORM model. However, should the database become larger and performance be an issue, which of these methods are best? Are there any other methods which I haven't considered?

• database
• database-design
• default-value
• addressbook

It sounds like you have an m:m (many to many) relationship between Organization and Address. So the best way to represent this in the database would be to introduce a new a table to represent this relationship.

I'm not sure if you mean default address as in default for the given company, or default for the given user when creating companies. In the first case, you would add this as an attribute of the newly created table representing the relationship. In the later case you could place a foreign-key in the user table, representing the default address.

With regards to performance, use integer keys and make proper indexes...! That said, it would be faster of course to skip the relationship table and just create a similair addresses for different companies on the same address. That would save you one join on the company+adresses lookup. However, this will be much slower if you need to find all companies on a given address, as you would have to read out different addresses and compare them.

So it all depends a bit on how you wanna use your data. I would go with "correct" option (a new relationship talbe), as it isn't a lot slower with the correct indexes and it gives you a lot more possibilities later on.

The next question is how do you get new users to pick an excisting address, rather than creating a duplicate entry.. This will be a challenge in your interface design, and the quality of the data you gather will depend a lot on it.

Personally I would go with the following:

Organization
-------------
OrgID
OtherOrgColummns

Address
-------------
AddressID
OtherAddressColumns

OrgAddresses
-------------
OrgID
AddressID
IsDefault

Though I can't be sure this will work based on your description.

A word of warning - there are approximately 10,000 ways to write out the same address. For example:

111 First Street
111 1st street
111 1st st.
111 1st str
etc.

I don't know how concerned you are about having people enter duplicates, but if that would be an issue I would recommend using a geocoding service to get the lat long for address and then using the lat long to determine if you already have an address in your DB... Just a thought...