Re: data modeling conundrum

bdeneaud_at_my-deja.com wrote in <8v3koj$m18$1_at_nnrp1.deja.com>:

>Thanks for the info!
>> Let me clarify the nature of the data...
>
>These number pairs are x,y coordinates of a 2-D plot (i.e. intensity
>vs.time). So, the parent record is a chemical compound and the
>x,y coord. are the resulting data from an analysis of that compound.
>
>Applications will query the database for a set of compounds and the
>associated x,y coord. data. Generally, the query will be for 200-1000
>compounds at a time (which would be 200*400 or 1000*400 rows if a child
>table was created for x,y data! which seems like too many rows to query
>quickly, i.e ~10-20seconds.) The appl will store the contents of the
>cursor/recordset in a datastructure and recreate the plots when say,
>the user clicks on a sketch of the compound. Having a child table for
>the x, y data would be a more elegant way to store the data, but
>considering the the growth rate 100,000*400 rows/year. Yeeks! And the
>average rows queried from the application each time would be 8000 to
>40,000 rows I am a little reluctant to take this path.
>Maybe this plot should created and processed into picture file (.EMF or
>GIF or something), then stored as a blob in the database or out on a
>network???
>
>

I really don't think these numbers are anything to worry about -- they are easily handled by Oracle. In my experience, non-relational optimization "tricks" (such as packing string columns with data values) are more trouble than they are worth (especially in the long run when changes/enhancements need to be accomodated). Good relational design and appropriate indexes should be what you're looking at. We're really only talking disk space here, which is cheap in comparison to programming resources....

Just one bonehead's opinion!

-- 
Gerard Averill
gaverill<at>chsra<dot>wisc<dot>edu