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
