On Mon, 20 Aug 2001 22:08:22 +0000 (UTC), <macosko@fas.harvard.edu>:
> orf is a primary key. It is a unique string that links the tables.
>
> Essentially, the setup is this: I am presented with data called
> transcription profiles. These contain two columns: orf, which is a unique
> representation of a biological gene, and induction, which is a number.
So, you have a list of
orf, induction
> Now, unfortunately, these profiles do not contain all of the known orfs,
> and also they can sometimes contain orfs that do not exist. so, when I
> want to load in a profile to my database, i need to select all the
> inductions from temp whose orfs exist in the master table. This master
Not sure what is temp... is this the list from above?
> table, yeast1, is very big--perhaps 600 columns. Basically, I'm just
Not sure what the number of columns has to do with it. Do you have
each orf in its own column for some reason?
UPDATE is used to modify a previously existing row. Is that what
you are wanting to do? Or are you wanting to insert new rows?
> adding columns to the database, and I'm looping it in Perl DBI. I
> wondered if there was a fast batch way to do that.
>
This is what makes me think you are adding columns for new
orfs. Seems like a bad idea to me if that is what you are doing.
(Of course the whole thing has me quite confused, soo...)
> On a related note, I had another question for everyone: I need to do
> calculations with these induction numbers--I need to select the entire
> table of inductions, load them into a matrix, and pass them to a
> computational C program through perl/cgi. This step is obviously quite
> rate-limiting, as it takes a very long time to select all from such a
> large table (yeast1). perhaps my database design is a little messed
> up--basically, I'm hoping someone will tell me the best way to load,
> store, and access this kind of data.
>
> Hope this clarifies!
>
You might try posting your schema... though then again, with
600 columns maybe that is not such a good idea.
