--- In Firebird-general@yahoogroups.com, Milan Babuskov <milanb@...>
wrote:

>
> They call it: Multivalued datatype
>
> http://www.regdeveloper.co.uk/2006/07/18/multivalued_datatypes_access/
>
>
> Or perhaps they just want to make Access compatible with FB ;)
>

Is there any reason to ever use them except to cause yourself
headaches? Surely a n:m table for defining many to many relationships
is not that complex to understand.

To take their example,

You have a table of people, you have a table of hobbies, and you have
a table that tells you which people have which hobbies. Google for a
SQL 101 tutorial on joins and within minutes you will know enough to
get the data you want for such a simple structure.

The only reason I can see to ever desire such a feature is to put a
few comma separated pieces of text in a UI somewhere, and even that
concatenation logic is best implemented in the application server or
client.

But I can't help but think that some 'power user' will end up writing
some database with all the companies important data with these sorts
of data types and then it is going to be an expensive operation to
retrieve and store the data correctly when it bites you later. By all
means put some logic in your 'new table wizard' to create the three
underlying tables, but don't hide them behind the UI as if it was a
dirty implementation secret, teaching them that their multi-value
fields are the right way to do it, and that those who use the 3 table
approach are working around the shortcommings of an engine. Imagine
the legacy programs that will be written.

Adam