<DIV>Thanks Adam! </DIV>
<DIV> </DIV>
<DIV>When I mentioned "array" I meant it as a data type for a column, but you might be talking about a microarray. Anyway it doesn't matter because the question I meant to ask is also answered.</DIV>
<DIV> </DIV>
<DIV>My logical error was in thinking of a plate as the base entity here, and a plate has 384 or 1536 wells. What is the best and correct thing to do is to model the WELL as the entity. </DIV>
<DIV>So there, a plate has wells, and wells have well_row, well_column, well_data, plate_id, and so fourth. Then a plate entity can have assay_id, detection_technology, reader_type, device_protocol_id, reader_id, etc..</DIV>
<DIV>then assays and readers and so forth are the other entities.</DIV>
<DIV> </DIV>
<DIV>It's making sense to me now. I'd still love to see how others have modelled this kind of thing in practice, like Spotfire or whatever.</DIV>
<DIV> </DIV>
<DIV>Thanks again.</DIV>
<DIV> </DIV>
<DIV>Mike<BR><BR><B><I>"Margolin, Adam" <margolia@wharton.upenn.edu></I></B> wrote:</DIV>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Mike,<BR>If you are using a relational database I certainly would not make tables<BR>with variable numbers of columns depending on the array configuration.<BR>What you want to do is make a table called Spotting_plates with every<BR>row uniquely identified by the Plate_ID and the well. When you spot an<BR>array you want to map each spot back to an entry in this table. To do<BR>this, define a table called Print_map with each row uniquely defined by<BR>an array configuration, and row, column, block on the spotted array that<BR>maps these values to a well on a spotting plate.<BR><BR>This is the general idea, but of course, there are some other<BR>intermediate steps. I can send you the scheme that we have developed<BR>for our arrays if you like, or for a more involved description you can<BR>surf around on this site: www.gusbd.org.<BR><BR>-Adam<BR><BR><BR>-----Original Message-----<BR>From: biod
evelopers-request@bioinformatics.org<BR>[mailto:biodevelopers-request@bioinformatics.org] <BR>Sent: Thursday, May 01, 2003 12:01 PM<BR>To: biodevelopers@bioinformatics.org<BR>Subject: Biodevelopers digest, Vol 1 #104 - 1 msg<BR><BR>Send Biodevelopers mailing list submissions to<BR>biodevelopers@bioinformatics.org<BR><BR>To subscribe or unsubscribe via the World Wide Web, visit<BR>https://bioinformatics.org/mailman/listinfo/biodevelopers<BR>or, via email, send a message with subject or body 'help' to<BR>biodevelopers-request@bioinformatics.org<BR><BR>You can reach the person managing the list at<BR>biodevelopers-admin@bioinformatics.org<BR><BR>When replying, please edit your Subject line so it is more specific<BR>than "Re: Contents of Biodevelopers digest..."<BR><BR><BR>Today's Topics:<BR><BR>1. 98/384/1536 well microplate database schema? (Mike Benway)<BR><BR>--__--__--<BR><BR>Message: 1<BR>Date: Thu, 1 May 2003 08:03:34 -0700 (PDT)<BR>From: Mike Benway <MBENWAY@YAHOO.COM><B
R>To: biodevelopers@bioinformatics.org<BR>Subject: [Biodevelopers] 98/384/1536 well microplate database schema?<BR>Reply-To: biodevelopers@bioinformatics.org<BR><BR>--0-1501308490-1051801414=:18737<BR>Content-Type: text/plain; charset=us-ascii<BR><BR>Hi.I have a process that generates lot's of data from 384 well plates.<BR>That is, three hundred -eighty four real numbers.The entity is the<BR>plate. Some plates can even be 1536 well formats. That's a lot of real<BR>numbers for a database table.384 columns might even be too many for any<BR>available database?It strikes me that this must be a very common<BR>application, and there has got to be a better schema for representing<BR>plate data. (as columns of arrays, or as blobs or what?)Does anyone have<BR>any knowledge of an open-source implementation that stores plate data in<BR>a database that I could look at?I can't believe that databases would be<BR>used just to store links to spreadsheets.Thanks<BR><BR>----------------------
-----------<BR>Do you Yahoo!?<BR>The New Yahoo! Search - Faster. Easier. Bingo.<BR>--0-1501308490-1051801414=:18737<BR>Content-Type: text/html; charset=us-ascii<BR><BR>
<DIV>Hi.</DIV><BR>
<DIV>I have a process that generates lot's of data from 384 well plates.<BR>That is, three hundred -eighty four real numbers.</DIV><BR>
<DIV>The entity is the plate. Some plates can even be 1536 well formats.<BR>That's a lot of real numbers for a database table.</DIV><BR>
<DIV>384 columns might even be too many for any available<BR>database?</DIV><BR>
<DIV>It strikes me that this must be a very common application, and<BR>there has got to be a better schema for representing plate data. (as<BR>columns of arrays, or as blobs or what?)</DIV><BR>
<DIV>Does anyone have any knowledge of an open-source implementation<BR>that stores plate data in a database that I could look at?</DIV><BR>
<DIV>I can't believe that databases would be used just to store links to<BR>spreadsheets.</DIV><BR>
<DIV>Thanks</DIV>
<P>
<HR SIZE=1>
<BR>Do you Yahoo!?<BR><BR><A<BR>href="http://us.rd.yahoo.com/search/mailsig/*http://search.yahoo.com">Th<BR>e New Yahoo! Search</A> - Faster. Easier. Bingo.<BR>--0-1501308490-1051801414=:18737--<BR><BR><BR>--__--__--<BR><BR>_______________________________________________<BR>Biodevelopers mailing list<BR>Biodevelopers@bioinformatics.org<BR>https://bioinformatics.org/mailman/listinfo/biodevelopers<BR><BR><BR>End of Biodevelopers Digest<BR>_______________________________________________<BR>Biodevelopers mailing list<BR>Biodevelopers@bioinformatics.org<BR>https://bioinformatics.org/mailman/listinfo/biodevelopers</BLOCKQUOTE><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/search/mailsig/*http://search.yahoo.com">The New Yahoo! Search</a> - Faster. Easier. Bingo.