Hi, > Von: Ashod Nakashian [mailto:ashodnakash...@yahoo.com] > > >The disadvantage clearly is that we need a few more bits when storing > that metadata in the SQLite database, instead of in our own file. But in > my eyes, this few bytes do not outweigh the overhead of inventing our own > metadata storage format, including correct synchronization, transaction > safety etc, which are already provided reliably by sqlite. > > The overhead in size isn't an issue (at least not a major one) rather the > overhead of *speed* is. At least that's my argument. I need to expand that > section with both approaches with pros/cons, but first let's agree on the > topic debated: to custom format, or to not.
My guess is: - For reading, the sqlite approach is not measurable slower, as we have to read the wc.db pristine table nevertheless. Reading 3 additional columns is not more effort than reading some data from a different file. - For writing/updating, my guess is that the processing amount of (re)-compressing the pristine data, writing it back to disk etc. is at least one magnitude larger than the amount we need for both updating the row in the wc.db or updating the extra file, so for a first implementation, we can go the easier way, which is storing in wc.db in my eyes. Best regards Markus Schaber -- ___________________________ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
