An irresistible comment :)

If I get you right, you're trying to store information as a serialized BLOB or String in a single column instead of spreading this information over several columns or tables and your hope is, that this will speed up your database access. Am I right, so far?

I think this journey will end soon, as you're abandoning all the favors of a relational DBMS! If you serialize the data you can neither search for it nor order the result by it or do anything else with it. I think serializing data in a database is a very tough decision which should be well considered. We store some information as a serialized string but we're absolutely sure that, at any time we need one piece of this dataset we need all the rest of it, too and we have absolutely no need to search or sort by the serialized data. So we gain some speed by eliminating some costly joins in the query. But as I said this isn't THE solution, it's only a small option for some very special niche use cases.

The BigTable project you're referencing to has a quite different goal. They try to create a very scalable DBMS which works a little different than a relational database and acts more like a sortable associative array than such a relational DBMS. But this does not mean, that they mix data in that array with each other by serializing it. The biggest difference to a "normal" DMBS like Postgresql or mySQL is the ability to scale very well over more and more and more hardware which is difficult task with traditional databases.

I think you should have a look at some kind of object relational mapper (http://en.wikipedia.org/wiki/Object-relational_mapping [en.wikipedia.org]). In PHP this might be Propel (http://propel.phpdb.org/trac/ [propel.phpdb.org]) or Doctrine (http://www.phpdoctrine.org/ [phpdoctrine.org]). Those frameworks will map objects in their object oriented sense to a relational database and let you access them in a more OO like way. This way you might not create the most efficient queries possible but you stay very agile with your data structures as you can easyli redefine your db schemas and remap them without the need to rewrite all your handwritten SQL in your application.

Anyway I think you should stop thinking about performance to much in the beginning! Just build something that works! Improving an existing system is for all means the better way to achieve performance. I don't know if you've planned to develop the framework as open source but if you do so, it will be a significant factor for the numbers of contributors you will get how usable your system is. And with this I do not mean how good your system perform but if it is able to run games. If it can, you will find people who use it and they will complain that it's slow and this is the point when people get involved! If you have just a barebone framework which is not capable to run any real world application nobody will get interested in it and you will have to lift all the heavy work on your own which makes it very likely that you'll give up in the middle of the game. Therefore my advice: Make plans, but don't plan (too much) about the performance. Align your concepts mainly about the usability of your framework! Performance will come. Look at Rails. It's a great to use framework which performed real worse in it's early days. But since it is so easy and elegant to use many many maaaaany people chose to stick with it and today those peope have created a very compelling and competitive framework, even in performance terms.

I hope this helps a little and my english wasn't too bad :/ But I'm trying to improve that :)

I would be glad to keep this discussion alive!

Cheers,

Thorben