views:

159

answers:

3

Or better said: When to use array as a field data type in a table?

Which solution provides better search results?

+2  A: 

I've considered this problem as well and the conclusion that I came to, is to use arrays when you want to eliminate table joins. The number of elements contained in each array isn't as important as the size of the tables involved. If there are only a few thousand rows in each table, then joining to get the 50 sub rows shouldn't be a big problem. If you get into 10's or 100's of thousands or rows, you're likely to start chewing through a lot of processor time and disk i/o though.

Dana the Sane
I could use the zip per county analogy. A county has so many zips. If a table T record needs to know of two counties, how many zips does the row know of? Do I keep an array of immutable county names in T and county-zip in T2?
Florin
I believe that GiST indexes can handle that sort of problem. In general, DBMS's don't deal well with this well though. This question also applies http://stackoverflow.com/questions/256997/hierarchical-tagging-in-sql#257106
Dana the Sane
A: 

The tables will always provide better search results assuming you're querying something within the actual array. With a subtable, you can index the contents trivially, whereas with an array, you'd have to literally create 50 indexes (one for each potential element within the array).

Will Hartung
I don't think this is the case, from what I've read, you can create indexes on arrays just like any other type of column type.
Dana the Sane
That may be correct, but all of the examples I saw were using expression indexes tied to specific elements of the array.
Will Hartung
+1  A: 

I avoid arrays for 2 reasons:

  • by storing more than one attribute value in a cell you violate the first normal form (theoretical);
  • you have to perform some extra, non-SQL related, processing each time you need to work with individual elements of the arrays (practical, but a direct consequence of the theoretical one)
Milen A. Radev
I'm a contractor (construction) and have little time for theory. Does that sound bad? I respect that but I do what comes first and works. Why do rdbms vendors provide array data types (for tables) if it is in violation of theory?
Florin
Yep, it sounds bad. Theory exists to provide solid foundation for the engineering. There are various reasons for the fact that SQL vendors ignore theory - they have little time for theory, they don't know the theory, they copy features from competitors etc.
Milen A. Radev
Point taken. I go back to my hammer and saw.
Florin