You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Further to conversations about molecule numbering (now captured in the Tech Ops wiki) and a SNAFU about two samples of the same molecule being tested and giving different data (#4 ), what is the best policy for recording data in the Master List on different batches of compounds? e.g. if a compound is synthesised several times and evaluated in different assays.
i) One row per MYOS number, and somehow indicating which data come from which batch or
ii) One row per batch, meaning multiple rows are possible for each MYOSXXXXX code. Is that annoying?
Am assuming the latter. So in #4 we need to retain the duplicate rows, not remove them, and instead distinguish with the batch codes.
The text was updated successfully, but these errors were encountered:
@mattodd The ideal solution would be to have a relational database, all in vitro screening data would be in a single table (or table per assay). The master list would be a view of the data using a lookup based on the molecule ID.
For in vitro screening data it would be fine to have a single Mol_ID in the master table and an average number for IC50 (average over repeats and batches). Including an N number would let people know the compound has been tested multiple times. If people want to see the individual results they would search the screening data table.
Perhaps something similar for current flat files, but I'm not sure how easy it would be to automate?
Further to conversations about molecule numbering (now captured in the Tech Ops wiki) and a SNAFU about two samples of the same molecule being tested and giving different data (#4 ), what is the best policy for recording data in the Master List on different batches of compounds? e.g. if a compound is synthesised several times and evaluated in different assays.
i) One row per MYOS number, and somehow indicating which data come from which batch or
ii) One row per batch, meaning multiple rows are possible for each MYOSXXXXX code. Is that annoying?
Am assuming the latter. So in #4 we need to retain the duplicate rows, not remove them, and instead distinguish with the batch codes.
The text was updated successfully, but these errors were encountered: