While I've never used the array datatypes ...

a) Whether or not it's supported in other software or interface layers shouldn't affect decisions
about datatypes to support ...

b) If someone wants it, it's there ... I feel about it like I do about freedom of speech -- even if
I don't like what you're saying, you should get to say it. You should get to have even the most
useless-seeming datatype, if that's what you really want.

c) It conforms to the relational model just fine. It wouldn't if, say, a query against a table that
had an array field would return one row for each value in the arrays. So long as the array is
treated as a value, it's fine. An integer is just an array of bits, a string is an array of
characters -- arrays can obviously be perfectly useful datatypes, conforming to the relational
model.

So long as your master/detail relationship is such that detail "rows" don't need to be referenced
anywhere, I suppose it'd not be a total goof to store them as arrays instead. If you can do the
equivalent of a C++ templated container, then eh, sure, why not? As Date and Darwen point out
in "The Third Manifesto", there are no actual rules to decide whether or not you can "legally"
store things as array values rather than as relation values. Relations are easier to get to, easier
to join, easier to manipulate in general ... but there's nothing written against storing one entire
relation per attribute per row in another relation, and somehow pulling that out and joining
against it. In fact, they make quite a big deal out of this (specifically because object-oriented-
database-system vendors harp on the myth that relational databases can only store numbers, dates,
and strings, and nothing more complicated.)

But hey, that's just theory. As I said, I've yet to find a use for FB's array datatype. Can an IN
statement take an array as a parameter? Maybe join rows via some sort of "... ON b.field IN
(a.allowed_values)" ?

-Philip


---------- Original Message -----------
From: Johannes Pretorius <johannes@...>

> I saw this posting on a newsgroup server
>
> //==============================
> > why is it not recommended to use array fields???
>
> They are barely supported -- you can do almost nothing with them in
> straight SQL, and forget about exposing them via ODBC or OLE-DB -- and
> they don't conform well to the relational model.
>
> //===================================
>
> This raised the question in my head, is this true. As I understand
> array fields can be handy in the following 2 aspects
>
> A) Saves space for mini master - detail relationship information
> B) QUICK in the 'A' scenario where the detail information is required. Do
> not need extra table to access
>
> Thus there MUST be a need for them to be created from the beginning anyways
> correct ??
>
> I just wondering what is the lists views on this ??
>
> Thanks in Advance for any comments
>
> Johannes Pretorius

------- End of Original Message -------