# Using an engine to create content with PHP - but how should it happen?

I need to create an engine that will allow me to add content to a website. The website is a browser-based game. This is a verbose engine that should be able to handle many different aspects of the project.

For an example, I want the developers to be able to insert "dreams" into the game. A dream is called each night for the player, and upon login they will see the dream they had. A developer will write up a cool dream for the game and insert it... but to where?

That's what I'm struggling with. Naturally, I think to myself that all content for the game will enter a database once a developer is done with it. However, the amount of content could be potentially very high, and it may be too hard on the server's resources once the game grows bigger - userbase included. The other way to do it to simply hardcode everything in: a simple "dreams" file that a developer would append their dream to. I cannot have such a system, however, if this project were to have five casual developers that don't know how to even open a PHP tag! ;)

Presently the best way I can imagine a player receiving a dream is to have a developer write it and then the database pulls the dream the player receives from the database. It seems unnecessarily arduous and I'm hoping that if I still must use a database, that you folks can steer me into the right direction for how to execute this efficiently.

• What do you mean by "engine"? – Tetrad Jun 2 '11 at 18:56
• A game engine, or as is probably the more relevant term... a content-management system. – Vael Victus Jun 2 '11 at 19:10

From reading your question and comments, I get the sense that you don't quite understand relational databases. So I guess my biggest recommendation to you, is for you to make sure you understand their strengths; the concepts of a primary key and a foreign key are especially important.

It is also difficult to discern exactly the question here - I think you're not even sure exactly what you are asking. Your actual question is "how should it happen?" and from the description you seem to be weighing the use of a database against hardcoding these dreams. And somewhere in there you seem to have a notion that a database won't be able to handle a large amount of data - which, I mean, isn't that sort of the point of a database? So if you think a database somehow can't handle some magnitude of data, you must not have much experience in the corporate world. Let me tell you, databases handle ungodly amounts of data and they retrieve it faster than you would think possible. They're made for that kind of thing.

Anyway, all of the above is subjective, and if you're dead set on storing these dreams in files, by all means do so. Just make sure you know your reasons, and that they are true, measured reasons. To guess that a database is slower is simply unfounded (or I'd like to know where you got that idea).

So go read about relational databases, know what a primary key and a foreign key are, and then look at this simple schema that I think is basically what you need:

table 'users'
id int primary key
...

table 'dreams'
id int primary key
description text
...

table 'userdreams'
id int primary key
userid int foreign key on users.id
dreamid int foreign key on dreams.id
... (maybe some data about whether the user has read the dream, or a timestamp)


(the above is, of course, pseudocode)

So the users table is where user details are stored - username, hashed password, etc. The dreams table is added to by the designers, and you can make a nice designer-friendly form that lets them write dreams and submit them into this table. And then the userdreams table is what ties the two together; each night you insert one row into this table per user, which has their userid and the id of the dream the user has (or more likely, when an user logs in you check if they haven't logged in since the previous day, and if not then assign them a dream and pretend as if the dream had been given to them overnight - but that's an answer to a different question).

Does this sound like the appropriate answer to your question? If not, please try to clarify a bit more. As I said, it's difficult to tell exactly what needs answering.

• Yes, it does, thanks! I actually work in a corporate environment that has about 300 people using our system. I learned about indexing, the value of primary/foreign keys, and caching all in one week where our system simply got too fat to sustain itself! ;) I appreciate this detailed answer. The notion of the database being slower is based on what I think is true of files vs. DBs - files should just be faster, because there's not even a query (no matter how optimized) being sent for the data. So naturally I think it'd be faster; though, not what I need to accomplish this. – Vael Victus Jun 2 '11 at 23:59

However, the amount of content could be potentially very high, and it may be too hard on the server's resources once the game grows bigger - userbase included. The other way to do it to simply hardcode everything in:

What makes you think that a system can cope with it in hardcoded form, but not when it's stored in a database? Databases are designed to store far, far, FAR more information than you would find in any typical code base.

Most online games, and indeed most sites, use a database these days. It shouldn't be arduous if you use a reasonable database API for it.

• Which API would you suggest for such a system? – Vael Victus Jun 2 '11 at 19:09
• +1. So many people seem to think DBs are slow and try to avoid them because they fear a huge bottleneck. It's really strange. – bummzack Jun 2 '11 at 20:44
• The best I know is to have an index on the tables holding the content. For MySQL, I've seen how fast indexes are, and I'm sure I'll be using memcache to my advantage. I imagined there would be some kind of file-based solution, or if I have to use a database, perhaps some special solution suggested by the answerers here. (mongoDB, a certain abstraction layer, etc.) – Vael Victus Jun 2 '11 at 20:56
• You don't need a special solution - almost any approach is good enough for the very undemanding use case you've suggested. The hard part is making sure your code to access it is reliable and secure - for that, an Object Relational Mapper is one approach. A search for 'PHP ORM' should help in that regard. But there is no need for a 'file based solution': a database uses files, but gives you a clear reading and writing API and many other benefits on top. – Kylotan Jun 2 '11 at 23:18

I would like to introduce you to this neat concept we call a content management system.

Also, listen to Kylotan.

• A simple, "just use the database" would've sufficed; I wanted to see if there was a better way than using the database and apparently there is not. I was learning WordPress three years ago, thanks. Though admittedly I didn't think to refer to my engine as a CMS. – Vael Victus Jun 2 '11 at 19:07
• @Vael Victus: That wasn't really the full intent of my referring you to the CMS concept; there's an existing body of thought and discussion surrounding CMSes, commonly occurring problems that have been found and solved, that might've been of benefit if you were unfamiliar with the concept. Who knows, just thinking of what you're doing as a CMS may itself be of benefit. – chaos Jun 2 '11 at 22:15