Yep, but with XML the new app will read the old data without a problem (unless there has been field delete's or renaming).
With the binary, there's a bit more to the coding (and testing) of the layout. That said, if you write the version number in the data file's header, you can switch out to a conversion routine which would use a lot of the old parser anyway. Where-as the XML is a b it harder to switch out to different parsers. So there's probably not a lot in it, but I know it's the binary ones that seem to get me to have get the pad and pen or a spreadsheet open while I do it ;) |-----Original Message----- |From: [email protected] [mailto:ozdotnet- |[email protected]] On Behalf Of GregAtGregLowDotCom |Sent: Tuesday, 4 June 2013 2:25 PM |To: 'ozDotNet' |Subject: RE: Lightweight database | |Agreed. Even with XML, you might to deal with what happens if the schema |changes ie: can your new app read an old saved set of data? | |Regards, | |Greg | |Dr Greg Low | |1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax | |SQL Down Under | Web: www.sqldownunder.com | |I think one of the first design parameters you need is how much data. If the |amount of data is small, then you can get away with xml. If it starts slowing down |you need to move to a different format such as a custom binary. | |XML - quick to code, easy, the customer can own their own data and work it out |themselves if needed. Can be slow as data increases. |Binary - slower to code, needs a lot of rules up front, speedy in use, needs custom |export as xml functions (perhaps) | |In both cases you end up loading all the data into memory, so there's a real upper |limit. If you get into paging it gets too complex and it's time for a real data |provider. | |XML suffers from having to parse the file, looking for special characters, then a |lookup match for each field for each record. |Binary on the other hand you can write the length of each record as the record |prefix so you just read in chunks of bytes, splitting each field either at fixed length |(really quick) or having variable length prefixed with their length. |Eg | |<User> | <FirstName>Greg</FirstName> | <LastName>Keogh</LastName> |<User> | |Becomes | |30 4 Greg 5 Keogh | |Where the 30 is the first dword (4 bytes), 4 is the next (4 bytes), then parse the |string which is 4 Char (wide is 8 bytes) next 4 bytes is the value of 5, then parse |the 5 chars (10 bytes) | |The problem with doing binary is if they change the schema, it's a real PITA to |change the code. | | | ||-----Original Message----- ||From: [email protected] [mailto:ozdotnet- ||[email protected]] On Behalf Of Greg Keogh ||Sent: Tuesday, 4 June 2013 12:25 PM ||To: ozDotNet ||Subject: Lightweight database || ||Folks, an app has just grown with a new feature that needs to store of |"users", ||"jobs" and "reports" and the joins between them, If I was using SQLite ||it |would be ||3 tables with joins. However, rather than use SQLite this time I'd like ||to |consider ||an alternative that's even more lightweight to setup and use. The app ||does |not ||currently use any database technology and the guys managing the project ||are actually scared of them. || ||Can anyone recommend an in-process database (not necessarily ||relational!) |that ||is has a friendly managed API, small footprint, not too complicated and ||is |easy to ||get going? I know this is a lot to ask, but there may be some NoSQL ||options around that I'm not aware of. The most important issues for me ||are: (1) |Minimal ||dependencies (2) Simple managed API. || ||I'm running a few web searches now for such things, and I can see ||Redis, |Mongo, ||Couch, Raven, db4o, Cassandra, Eloquera, Lucene, and the list goes on ||and |on. ||There are too many choices and it would take many days of hard slog to ||work |out ||which one would be suitable. So perhaps someone has already been ||through |this ||process?! || ||I've been tempted many times over the last 10 years to write a pure ||managed single-file database with indexes, and nothing much else (no ||transactions, |no ||client-server, no schemas, etc). However, I decided to leave it to the |experts, and ||it looks like there are too many of them, and they all over-engineer ||their |works. || ||Cheers, ||Greg K | |
