views:

419

answers:

3

For reasons that are beyond my control I need to store huge arrays (10000+ entries) in database rows, and it has to be easy to access each index of the array individually, which means I'd rather avoid serialization/blobs, if at all possible.

So my first idea, and the actual question here, is can I increase max columns for Oracle in anyway?

Or is there an easy way to say store the array over a few rows and hide the implementation below the surface (I'm thinking stored procedure here).

Any other suggestions are also welcome!

+2  A: 

Not sure about increasing the max columns. However, Why not split it across multiple tables which each table sharing the same unique ID. This implementation will be more easier than storing it over multiple rows.

Dheer
I think that "SELECT item FROM tbl WHERE arrayid = ? and idx = ?" is far easier and nicer than generating an SQL string "SELECT item" + foo + " FROM tbl" + whichtbl + " WHERE arrayid = ?"
JeeBee
I think Sebastian's solution is "better", however to be honest with you Dheer, I originally was thinking the same thing as you here :)
Robert Gould
@Dheer, You want to create a new table for each array? Creation of tables is slow and the query executer becomes really slow too because each SQL statement it sees is different (because the table name is different) and that frustrates the library cache.
tuinstoel
@Tuinstoel, What? Creation of tables is slow? WTF does that have to do with anything? and the executer what? yes with each table name there's a hard parse, but that's far from "really slow"
+5  A: 

The maximum number of columns is a constraint of the database engine. So no luck there.

I don't know how many rows your database will contain, but it could be a solution to use a table that stores three fields: ArrayId, FieldIndex, Contents. Each array field is a single row in the database. If you put a combined index on ArrayId and FieldIndex, access should be pretty fast.

This solution would also allow for variable-length arrays.

Sebastian Dietz
Please don't do it this way. This is a derivative of the generic data model and it's virtually impossible to make perform. But if this answer is bad, the question is just as bad. 10k columns makes me think someone needs to spend more time in design.
+2  A: 

Why not store the array as a Blob?

It is very unlikely that anyone would ever code "Where Acol999 = 42 or Acol1000 = 42 ..." in SQL so if you just want to store and retreive than store it as a Big Clob or Blob depending on your data.

This will be much quicker qnd involve much less code.

If you eally want to query the contents than you really need a separate table with 1 - ONE - row per array cell. You will then be able to query this sensibly.

CREATE TABLE ARRAY_CELLS (
     PARENT_ID INT NOT NULL,
     INDEXNUM  INT NOT NULL,
     VALUEOF   LONG NOT NULL
    PRIMARY KEY(PARENT_ID,INDEXNUM)
);

You can then run queries like:-

 SELECT PARENT_ID from TABLE_ARRAY_CELLS WHERE VALUEOF = 42 GROUP BY PARENT_ID;

Which will give you a list of all the Arrays that contain value 42.

James Anderson
Your second solution is probably what I'll finish up doing, because in this case its actually VERY likely that people will be updating single Columns of the Array (because of the Abstraction layer, users won't be writing SQL directly), so the Blob isn't as good as it would normally be
Robert Gould
Long is obsolete, long is not a big integer field but a field that used to be used for storing large amounts of data. Long is a predecessor of the clobs and the blobs of today.
tuinstoel
I do however agree with the second solution if you change valueof long into valueof number(10).
tuinstoel