views:

202

answers:

7

I haven't got any experience with databases, but intends to learn it and use it on a web project I'm planning.

Though, I've got advice from a pal of mine that the use of databases should be quite more extensive than I planned. He believes in keeping almost all of the data in databases, where I find that databases are most convenient regarding perhaps user data (just tiny pieces of data), and page content data and the like (everything that's not just very tiny pieces of data) in static files - without having any knowledge to build that assumption upon.

  • What would be the better solution? Minimum data in databases, or as much as I can find ways to store in them effectively?
  • Is there a performance difference between the use of static files and databases?
  • Would the best solution depend on general site traffic?

I intend to use a combination of PHP and MySQL.

+2  A: 

The database is the right place to keep things that are strictly data. Flat files simply cannot be indexed with nearly the same speed as data in a database. On the other hand, setting the database up will require more learning earning.

Binary data like photos isn't so great in databases.

Chuck Vose
Actually, modern mySQL and other databases do fine putting stuff like jpg and png files into binary large objects.The reason people like to put these media assets into ordinary files, even in systems like WordPress, Joomla!, and Drupal, is that the HTML model for delivering them to browsers is very file-centric.Surely taking a look at WordPress, Joomla!, or Drupal will be an excellent learning experience.
Ollie Jones
Compared to the performance of apache serving static files the database is utterly incapable compared. Drupal doesn't store files in the database, only information about the files. There's a lot of google info about it but I found out the hard way that the cost of bootstrapping any framework in order to get data out of the database is just much bigger than apache looking through the filesystem to find out if the file is there or not.
Chuck Vose
A: 
  • I would say: everything in the database. Databases are optimized for these kinds of things. Most blogging software also use databases for content, it's safe. Edit: oh, binary files are indeed better as files. But also MySQL can handle them safely. If you have like 1 photo, it's okay to store it in the database (since it's easier to maintain), but if you host, say, 10.000 photos: use files instead, and keep reference of the files in the database (their location, etc.).
  • Absolutely: databases are, again, optimized. Under the hood, a database uses files: but you don't have to care about this anymore.
  • MySQL database is absolutely fine for general site traffic.

PHP and MySQL is a good choice.

Pindatjuh
+2  A: 

Databases aren't the only means of persistent data storage, they're simply the most common.

There are document/blogging engines that don't use databases at all. When a page is created, changed or commented on a static html file is created or modified. For example, Movable Type.

Likewise you can have purely in-memory storage systems where if the system is turned off the in-memory data is simply reconstructed. Or memory contents are dumped then restored and no database is involved. This is typically done in systems with an extremely high throughput or that requires extremely low (microsecond level) latency.

Your question can't really be answered because the answer to everything you've asked is "it depends" and you can probably make it work however you do it.

I will say this: don't be too concerned about performance until you actually have a problem. Most performance problems you'll encounter will probably come down to indexes and primary keys in the database.

PHP and MySQL is a fine choice.

cletus
Yes, that's perhaps alternatives, but are they better? Performance-wise? In a database, you can easily find what you're looking for; in a HTML file that would be modified each time a page is changed, you would have to do some searching to find the things you would change, and then change them. For sites with large amounts of traffic, wouldn't that be downright stupid?Else some good points.
Sune Rasmussen
I disagree regarding concern over performance - flat file vs db is a design choice, where you can code yourself into a corner.
OMG Ponies
Done correctly, flat file vs DB is an implementation detail.
cletus
+3  A: 

If you want to be able to search specific data based on several parameters, then you really need to use a database. The SQL language namely offers you the WHERE clause exactly for this. Also whenever data is to be created and updated, the database is the best choice, because it provides constraints to ensure the uniqueness of the data to certain degree. Also relations between data is best to be managed by the database (using foreign keys and so on).

For example an user profile is best to be stored in a database. Also user-controlled input must be stored in a database. Server-side include/template files are on the other hand best to be stored as normal files in the server's local disk file system, because there's no need to search in it. You can eventually store filenames in the database if you want to "link" them with some more (meta)information (e.g. menu/submenu). The same applies to binary files (images, downloads, etc), you don't want to have them in a database, unless you want a (extremely) high degree of portability.

BalusC
A: 

Also if the data manipulation requires transactions, databases are almost always the only good solutions.

sibidiba
A: 

Mysql is one of the common databases with data integrity. If you've planned to store a large data, mysql is best to use. Security should also be considered in using database. Mysql is much secure and easy to use, you can also search all over the net for some better documentation and examples.

Trez
A: 

In my opinion - you need a reason no to store data in the database. |But I think you should also consider non-relation databases like google datastore http://code.google.com/appengine/docs/python/datastore/ or other similar things.

David Gruzman