On Wed, Aug 11, 2010 at 1:09 AM, Alex Hutton <[email protected]> wrote: > An idea I had the other day, and this is for dealing with data > compartmentation in games, was to write a game in C and use sqlite for > all the data. I've never used sqlite so I don't know how the > performance would go, but it seems like a good idea to store all the > data in a relational database as it makes it less likely that the data > structures would have to be refactored during development and it > allows me to avoid having to use 'objects'.
I don't know what granularity of data you're thinking of storing in the database. If it's very fine grained data then I'd expect you're going to hit concurrent writing lock-scaling problems (see, eg http://www.sqlite.org/faq.html#q5 ) Part of the reason why systems like git or hg don't use a standard database for their backends is that a general purpose database generally has limited means for expressing which subsets of the data are independent, and hence what the minimal locking is for writers (and reading whilst something may be writing), whereas, eg, the git backend knows due to the data struture and code design that it can do _almost_ everything without locking. (That's part of why it scales to things like Ingo Molnar's automated "Merge every single patch in every single remotely relevant patch queue into one mammoth kernel and try and boot it for regression testing".) One of the big advantages of "conceptual objects" (whether they're actual language objects) is that since they can have different implementations they can have different access semantics. As I mentioned in a different thread, if you look at a lot of "praised" old code it's perfectly well designed for the realities of computer architecture at the time it was written, but nowadays a lot of it is either "middlingly effectively written" or sometimes "PLEASE, PLEASE don't write code that way" examples. Just because new innovations aren't a magic bullet and are often overhyped doesn't meant they're worthless. Personally, I think it's a shame that there's no widespread language that has compiler/run-time support for "immutable once set-up" variables in this multicore age. (You can have a design in which a variable your design treats as immutable in C, but there's no inherent support, eg, for detecting violations or cloning copies for core's with a different cache, etc.) -- cheers, dave tweed__________________________ computer vision reasearcher: [email protected] "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
