> concerned with organizational clarity and correctness than efficiency >From my personal experience, Sqlite is so bloody fast I simply side table efficiency until it needs to be looked at. I can load 1.5 million name address records (500 bytes each), a second table of 3 million records (same size), then pick and choose from the latter and put into the former to increase postal discounts, and do that in 30 minutes or under. I have no complaints.
Kudos to Sqlite and the freedom they have given me. dvn On Thu, Oct 9, 2014 at 11:17 AM, Drago, William @ MWG - NARDAEAST < william.dr...@l-3com.com> wrote: > > > > The question I have is, 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. > > > > For SQLite, except in exceptional cases such as huge (multi terabyte) > > databases or slow media, it is more efficient to have one big table > > rather than several smaller tables. > > Good to know. Since this is a small, low volume database I'm more > concerned with organizational clarity and correctness than efficiency. > > > > > At a first glance, when I see two tables with identical column > > definitions, I tend to feel that they should be merged into one table > > with one additional column. > > That was my gut feeling. I could combine even further by using just 4 > columns, but I thought the code might be less complicated by keeping them > separate: > > ID > Frequency (either HF or LF) > VName (Offset, v10...V200) > MeasuredVoltage (actual recorded value) > > Thanks for your reply, Simon. > > -Bill > 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