Flat file databases

Well, what is the nature of the flat databases. Are they large or small. Is it simple arrays with arrays in them? if its something simple say userprofiles built as such:

$user = array("name" => "bob", 
              "age" => 20,
              "websites" => array("example.com","bob.example.com","bob2.example.com"),
              "and_one" => "more");

and to save or update the db record for that user.

$dir = "../userdata/";  //make sure to put it bellow what the server can reach.
file_put_contents($dir.$user['name'],serialize($user));

and to load the record for the user

function &get_user($name){
    return unserialize(file_get_contents("../userdata/".$name));
}

but again this implementation will vary on the application and nature of the database you need.

You might consider SQLite. It's almost as simple as flat files, but you do get a SQL engine for querying. It works well with PHP too.

In my opinion, using a "Flat File Database" in the sense you're meaning (and the answer you've accepted) isn't necessarily the best way to go about things. First of all, using serialize() and unserialize() can cause MAJOR headaches if someone gets in and edits the file (they can, in fact, put arbitrary code in your "database" to be run each time.)

Personally, I'd say - why not look to the future? There have been so many times that I've had issues because I've been creating my own "proprietary" files, and the project has exploded to a point where it needs a database, and I'm thinking "you know, I wish I'd written this for a database to start with" - because the refactoring of the code takes way too much time and effort.

From this I've learnt that future proofing my application so that when it gets bigger I don't have to go and spend days refactoring is the way to go forward. How do I do this?

SQLite. It works as a database, uses SQL, and is pretty easy to change over to MySQL (especially if you're using abstracted classes for database manipulation like I do!)

In fact, especially with the "accepted answer"'s method, it can drastically cut the memory usage of your app (you don't have to load all the "RECORDS" into PHP)

One framework I'm considering would be for a blogging platform. Since just about any possible view of data you would want would be sorted by date, I was thinking about this structure:

One directory per content node:

./content/YYYYMMDDHHMMSS/

Subdirectories of each node including

/tags  
/authors  
/comments  

As well as simple text files in the node directory for pre- and post-rendered content and the like.

This would allow a simple PHP glob() call (and probably a reversal of the result array) to query on just about anything within the content structure:

glob("content/*/tags/funny");  

Would return paths including all articles tagged "funny".