Good read. So, SQLite keeps a record of the length of each field, and determines the result of a length by returning a value stored at a 'black box' level, similar to the Delphi/Pascal way of non-null-byte-string termination. Perfect. Also, I noted your comment that just using length versus adding extra code to manage an extra field shouldn't show any difference, so I'll leave it at that.
The purpose of my application is for an archiving setup for a game I play. SQLite is perfect for this since I will be hopefully be converting this app to multi-platform for at least Linux and maybe Mac if the game plays on it. Right now, the code is Win32 coded under D2010 right now as I'm comfortable with the IDE and components, but once I get to the point where the code functions, I'll be able to at least take a second stab at getting something working in Lazarus/Free Pascal. As mentioned, this game stores only 13 files (10 save slots for the user, 3 for "automatic" backups if the option is set). The only indication of where I'm at in the game universe at that time is the date/time I saved, the amount of money, and what system I'm in, which is really pointless when you hang around the same area a lot (Home base advantage and all), or come back to the game after a long period of time. The game gives no option to enter a description of the save, or a sign as to why I saved at that point except via a "game time dialog" hint that I'll get my rear end handed to me on a silver platter by the enemies, or, the better-than-off chance that I'll run into a gate accidentally... With this app I'm writing, it'll basically eliminate the 13 slot problem, and EASILY step back a few saves without leaving the game environment. What I'm calling "rolling saves" will allocate a user-defined set of slots that allows me to go back a few "saves" while still in game. As an example, if I assign save slots 5-10 as to be used as rolling saves, slot 5 would be the most recent save, 6 would be the one previous, 7 would be the one previous to that, so on and so on. Of course, direction of this sort is user defined as well. So the question of how SQLite handles length() for a blob field comes into play as I didn't want it to count, byte for byte, potentially gigabytes of data just to verify two key aspects of a physical file. If it did count bytes, the extra field obviously would have been the route to go as I'm already reading that data from the drive for verification purposes. The file time stamp "should" be enough, but there is that one time of the year when 2am comes twice in a day in most parts of the world, so, covering that aspect with the concept of looking at file sizes as part of unique identification. **As I write this, I just thought about reading a chunk of the file on the drive and running it against an MD5 or CRC64/128 check sum algorithm, and storing that result in the database instead of relying on a file size.... hmmm... That'd be a balance between speed and accuracy. I don't want to chew too much IO time on lower end machines. Both cases don't give a 100% accurate assessment to a truly "unique" file, but I wonder which would give the better rate of accuracy? Maybe integrating all three? .. Sorry.. rambling.. tired... heh The question about how frequently data gets added depends on the factors of my remembering to save, my actually playing, and what options I have in this tool to monitor. Average size looks to be 13meg, but I've only seen saves on my system, and not others. As for saving to the SSD.. I hear ya... I love the speed (Raid-0 dual 250gig SATA3) but hate that they'll die due to running out of good memory blocks, but, at least not as 'randomly' as a platter drive, and ooohhh so much quieter. ;) However, while developing this app on another machine with just platter via ESATA, it took about 5 seconds to dump the 128meg data into the database. I'm at home as I write this email, so will look forward to seeing how well the tool performs while developing. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
