Don,
Thanks for weighing in on this. I'm going to experiment with the single table
solution and the 3 table solution below and see where I end up. The cream
always rises to the top.
Thanks to all who replied to this thread,
-Bill
CREATE TABLE UUT(
DatasetID INTEGER PRIMARY KEY,
Location TEXT, --Factory location.
ModelNumber TEXT,
SerialNumber TEXT,
TestDate TEXT,
ATEVersion TEXT,
CalStatus TEXT, --Pass or Fail.
Par0 TEXT --Sent to EEPROM.
);
CREATE TABLE CalData(
DatasetID INTEGER REFERENCES UUT,
Frequency TEXT, --Either LF or HF.
vOffset REAL, --Voltage with RF Off.
v10 REAL, --Voltage at 10% Std.
v20 REAL,
v50 REAL,
v100 REAL,
v200 REAL --Voltage at 200% Std.
);
CREATE TABLE Stimulus(
DatasetID INTEGER REFERENCES UUT,
Frequency TEXT, --Either LF or HF.
Target REAL, --dBm, 100% Std.
Source REAL, --dBm, Source output.
Pind REAL --dBm, as displayed on power meter.
);
--
Bill Drago
Senior Engineer
L3 Communications / Narda Microwave East
435 Moreland Road
Hauppauge, NY 11788
631-272-5947 / william.dr...@l-3com.com
> -----Original Message-----
> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> boun...@sqlite.org] On Behalf Of Don V Nielsen
> Sent: Thursday, October 09, 2014 12:21 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Single large table vs. several smaller tables
>
> I suggest you group columns into a structures that you are comfortable
> with. I have a name, own a home, and have one car. Everything is
> singular to me, an individual. So if I have a table Individuals, do I
> want 25 columns that encompass name, address, year, make, and model of
> my car, type of home, how many windows it has? At some point, even if
> the information is 1 to 1, it makes sense to segregate related data
> into a table and join it.
>
> I don't really understand your particular data. But if you can
> rationalize that these pieces of data are best written on a 3x5 note
> card by itself, then create a table and join them. It's not all about
> efficiency.
>
> just my opinion
>
> On Thu, Oct 9, 2014 at 11:03 AM, Drago, William @ MWG - NARDAEAST <
> william.dr...@l-3com.com> wrote:
>
> > Clemens,
> >
> > That's 24 columns per unit, not rows. There's no duplicate
> information.
> >
> > Avoiding joins is something I considered. Thank you for confirming
> > what I was thinking.
> >
> > -Bill
> >
> >
> > > -----Original Message-----
> > > From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> > > boun...@sqlite.org] On Behalf Of Clemens Ladisch
> > > Sent: Thursday, October 09, 2014 10:46 AM
> > > To: sqlite-users@sqlite.org
> > > Subject: Re: [sqlite] Single large table vs. several smaller tables
> > >
> > > Drago, William @ MWG - NARDAEAST wrote:
> > > > An automatic test system that I designed generates 25 data
> > > > elements for each unit tested. [...] should I lump everything
> > > > together in one table just like the .csv file or should I create
> > > > several smaller tables that group similar parameters?
> > > > I'm not sure what would normally be done. I think the database is
> > > > normalized properly in either case.
> > >
> > > When you have 24 rows for each unit, this sounds as if the unit
> > > information is duplicated. You have to decide if it would make
> > > sense to have a separate table for units.
> > >
> > > Splitting up for "similar" parameters makes sense only when this
> > > similarity has an effect on your queries, i.e., if it would be
> > > easier to write "SELECT * FROM LFCal". That's unlikey if you also
> > > have to do a join with UTT.
> > >
> > > It might make sense to do the split as an optimization, but only if
> > > the amount of data in the combined table were large enough to
> > > overwhelm your computer. This does not appear to be the case.
> > >
> > >
> > > > CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail
> > > > and
> > > ...
> > >
> > > This e-mail contains public information intended for any subscriber
> > > of this mailing list and for anybody else who bothers to read it;
> it
> > > will be copied, disclosed and distributed to the public. If you
> > > think you are not the intended recipient, please commit suicide
> immediately.
> > > These terms apply also to any e-mails quoted in, referenced from,
> or
> > > answering this e-mail, and supersede any disclaimers in those e-
> mails.
> > > Additionally, disclaimers in those e-mails will incur legal
> > > processing fees of $42 per line; you have agreed to this by reading
> > > this disclaimer.
> > >
> > >
> > > Regards,
> > > Clemens
> > > _______________________________________________
> > > sqlite-users mailing list
> > > sqlite-users@sqlite.org
> > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> > CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and
> > any attachments are solely for the use of the addressee and may
> > contain information that is privileged or confidential. Any
> > disclosure, use or distribution of the information contained herein
> is
> > prohibited. In the event this e-mail contains technical data within
> > the definition of the International Traffic in Arms Regulations or
> > Export Administration Regulations, it is subject to the export
> control
> > laws of the U.S.Government. The recipient should check this e-mail
> and
> > any attachments for the presence of viruses as L-3 does not accept
> any
> > liability associated with the transmission of this e-mail. If you
> have
> > received this communication in error, please notify the sender by
> > reply e-mail and immediately delete this message and any attachments.
> > _______________________________________________
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> >
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and any
attachments are solely for the use of the addressee and may contain information
that is privileged or confidential. Any disclosure, use or distribution of the
information contained herein is prohibited. In the event this e-mail contains
technical data within the definition of the International Traffic in Arms
Regulations or Export Administration Regulations, it is subject to the export
control laws of the U.S.Government. The recipient should check this e-mail and
any attachments for the presence of viruses as L-3 does not accept any
liability associated with the transmission of this e-mail. If you have received
this communication in error, please notify the sender by reply e-mail and
immediately delete this message and any attachments.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
