LeTubs wrote:
I have few questions in realtion to arrays, I assume that
they are not available as a data type, is this correct ?
I believe that is correct. I find no mention of array column types in
the MySQL documentation. FWIW, arrays are not standard SQL data types,
they are extensions offered in some RDBMS implementations.
One workaround would be to store an array in a BLOB column, and leave it
up to your application code to store the array correctly and to fetch it
correctly. But this wouldn't be SQL support for arrays because you
probably can't fetch an individual array element in a SELECT, or update
an individual array element in an UPDATE, or reference individual array
elements in conditions.
Defining a one-to-many table to store each of the 1000 ints per record
would cost more storage space, because you'd need a foreign key field
referencing the parent table. This would add up quickly if you have
many records. Still more space would be required if you also need to
note the position in the array for each element; that is, if the order
of the elements is important. I infer from your example that you'd need
to record the close date for each element:
CREATE TABLE dailyclose (
VARCHAR symbol(20) # =< 1+20 bytes
REFERENCES stock_or_fund(symbol),
INT beta, # 4 bytes
DATE close_date # 3 bytes
);
On the other hand, hard disks are amazingly inexpensive these days, and
buying a new 120GB disk might be cheaper than the amount of extra
programming time it would cost you to work around the lack of array
support in SQL. ;-) There's sometimes a tradeoff between storage
expense, computational expense, and code development expense. Don't get
too focused on just one of these and ignore the others!
And another advantage of the one-to-many table is that you aren't
constrained to 1,000 entries; it can keep growing to as many entries as
you have data for. Also, doing slices for a given calendar year or
other conditions would be pretty easy, since you'd have a DATE field.
Regards,
Bill K.