A question

[Dayo]

I will be making some thing soon that will have loads of "locations" I was gona use a db but the information I was gona store on each location would be huge so I had an IDE of making a file for each ovation eg 1.location.php then call that page and prosess the informaion inside would this be better or worse then a db?

[Spudinski]

What type of data would the opposed cities hold? You can mix them alternatively.

[Zeggy]

Databases are designed to contain large amounts of data... Don't hesitate to use a database if it seems appropriate for your kind of data.

Storing purely data, a database has several advantages over a file system - selecting specific columns/rows, ordering, joins with other tables, caching, indexes etc.

However, if you know you're not going to need any of those features, and you don't need to do any searching when selecting your data (ie. you know exactly which file to include/read when you need it), then simply using files would work just as well if you prefer to work with files.

[Dayo]

Well the data I would be storing is the folowing

Location name/id

locations avalable to travel to from there

HTML (each location will be diffrent)

location type (bank | battle | shop | etc...)

Description

there is more can't go into it as it is part of a game I'm coding

but each location page will have 100-600 lines of coding and there will be about 250 locations

plus i'm gona try to keep a small db as I can as after time goes by I want it easier to manage with only a few tables ... Users, logs, mails, chat msgs, inventory, NPCs

[DigitalGerm]

Questions to ask yourself:

1. Dose each location need a specific and different HTML template ? or you could just use one Template for all?

2. The location have sub locations ? such as hotel bar, Cartier ?

3. Do you need to load all locations in one session ? Can you alternate them with Ajax, jquery post ?

4. Do you need to edit the data locations ? Or just read the content ?

If your average answer is yes. Then go for DB without hesitation. Inner join is better then open, load, read and link multiple files.

Not to mention if you want to edit one you have to load all the data page ( assuming it's xml, for reading you don't need to load all xml file witch is plus for file );

It's strongly recommend to use Ajax to reduce the load and process request from server.

go for DB mate.

[Zeggy]

each location page will have 100-600 lines of coding and there will be about 250 locations

What are the 600 lines of coding? PHP? HTML?

Are your 250 locations really going to be unique? Or could you abstract them out of the database and only store the parts that are different in each location?

 

'm gona try to keep a small db as I can

That's like saying you want to keep your game as small as you can. The best way I find to do that is to not allow people to register. Your database will surely be very manageable then ;)

But really, if you restrict yourself to a small number of tables, then your game either doesn't have many features, or you are stuffing too much data into each table, possibly data that shouldn't belong there. If it's the former, then your game might be boring. If it's the latter, then your database still won't be manageable.

Think of it like a closet. If you have a big closet, you can manage your clothes more easily. If you have a small closet, you'll be stuffing too much into the closet and won't have space to organise them properly. Looking for clothes will be messy and will take a lot of time.

Tables are containers, just like closets. A game with 1000 players will produce a certain amount of data, regardless of whether you are using 5 tables or 50 tables. There really isn't a huge difference in either scenario, so you shouldn't limit your tables based on this idea, you should base your tables on what you need.