views:

122

answers:

4

My DBA told me to use a user-defined SQL datatype to represent addresses, and then use a single column of that new type in our users table instead of multiple address columns. I've never done this before and am wondering if this is a common approach.

Also, what's the best place to get information about this - is it product-specific?

+1  A: 

There are a number of other questions on SO about how to represent addresses in a database. AFAICR, none of them suggest a user-defined type for the purpose. I would not regard it as a common approach; that is not to say it is not a reasonable approach. The main difficulties lie in deciding what methods to provide to manipulate the address data - those used for formatting the data to appear on an envelope, or in specific places on a printed form, or to update fields, worrying about the many ramifications of international addresses, and so on.

Defining user-defined types is very product specific. The ways you do it in Informix are different from the ways it is done in DB2 and Oracle, for example.

Jonathan Leffler
A: 

I would also rather avoid using User defined datatypes as their defination and usability will make your code dependant on a particular database.

Instead if you are using any object oriented language, create a composition relationship to define addresses for an employee (for example) and store the addresses in a separate table.

Eg. Employees table and Employee_Addresses table. One employee can have multiple addresses.

Kalpak
+1  A: 

As far as I can tell, at least in the SQL Server world, UDT aren't used very much.

Trouble with UDT is the fact you can't easily update them. Once created and used in databases, they're almost like set in stone.

There's no "CREATE OR ALTER (UDT)" command :-( So to change something, you have to do a lot of shuffling around - possibly copying away existing data, then dropping lots of columns from other tables, then dropping your UDT, re-creating it with the new structure and reapplying the data and everything.

That's just too much hassle - and you know : there will be change!

Right now, in SQL Server land, UDT are just a nice idea - but really badly implemented. I wouldn't recommend using them extensively.

Marc

marc_s
Agree with you, I would not use UDFs in SQl Server for any reason until they fix the implementation.
HLGEM
A: 

user-defined SQL datatype to represent addresses

User-defined types can be quite useful, but a mailing address doesn't jump out as one of those cases (to me, at least). What is a mailing address to you? Is it something you print on an envelope to mail someone? If so, text is about as good as it's going to get. If you need to know what state someone is in for legal reasons, store that separately and it's not a problem.

Other posts here have criticized UDTs, but I think they do have some amazing uses. PostgreSQL has had full text search as a plugin based on UDTs for a long time before full-text search was actually integrated into the core product. Right now PostGIS is a very successful GIS product that is entirely a plugin based on UDTs (it has GPL license, so will never be integrated into core).

Jeff Davis