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
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 <
> 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.
> > -----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: email@example.com
> > 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
> > firstname.lastname@example.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 mailing list