Flat file or Mysql? [Poll]

[cordoprod 0]

You vote.

[MadTechie 0]

really depends in the site setup.. if SQL is already used then why not.. if the news system is just a very simple one then why not use flatfile!!

 

more info needed

 

 

PS i voted SQL as you can do more advanced stuff later!

[GingerRobot 1]

Flat files are a pain. The whole point of databases is to store data; use the right tool for the job.

[cordoprod 0]

Yeah, I guess. But last time I got alot of complaintings because they didn't had a db, and blabla..

[LiamProductions 0]

mySql, But shouldnt this be in Polls

[zq29 2]

Yeah, I guess. But last time I got alot of complaintings because they didn't had a db, and blabla..

If 'they' want a database based application, they need to be installing a database server, not complaining.

 

Moved to polls.

[charliepage 0]

Of course using flat file for news isn't a horrible idea and it could be the better option in a very small amount of occasions, but in general, using MySQL is frankly all-around better. Much easier, much much more advanced (in the way, that you can use MySQL for just about unlimited possibilities) and it is on a very high majority of hosts. I suppose I am just a tad biased.

[slapme 0]

MySQL definatley

[karltanav 0]

Ive used plain txt files and those are a nightmare, nothing compared to the SQL databases in order to have the information well sorted and saved

[sureshp 0]

Shall we use SQL Lite for this one? it is also well sorted and saved i think so.

 

[Bladescope 0]

Always used MySQL.

[unsider 0]

MySQL *quick, easy, pretty reliable

flat files *pain in the arse

[Daniel0 2]

flat files *pain in the arse

 

Why?

[unsider 0]

I may be a little misguided here, but from the little I've used and read about them.

 

I think they're a little out-dated/better methods avaliable, therefore resulting in ineffeciency.

 

Hmm, now that I look back I could have used a better word to describe them...I guess there are just better, more effecient methods, and in this case mySQL.

[Daniel0 2]

I take it you haven't heard of SQLite. It stores the entire database in a single (flat) file. SQLite is in many instances more efficient than running running daemons such as MySQL, Oracle or PostgreSQL. It's used by Firefox, iPhone, Skype and Trac just to name a few. Your sig says you're using Mac OS X, so it's already on your computer.

[unsider 0]

I take it you haven't heard of SQLite. It stores the entire database in a single (flat) file. SQLite is in many instances more efficient than running running daemons such as MySQL, Oracle or PostgreSQL. It's used by Firefox, iPhone, Skype and Trac just to name a few. Your sig says you're using Mac OS X, so it's already on your computer.

 

Nope, I haven't, I'll have to check it out.

[markjoe 0]

There situations that flat files are just fine and even easier, they are just few and far between.

 

I needed to make an ultra simple web front end for our FTP server (upload+download).

So i wrote about 20 lines of HTML+PHP and used a date/time algorithm for the password instead of installing an SQL database just for one username and password.

Flat file would have worked just as well, I just went one step even lazier.

[448191 25]

I take it you haven't heard of SQLite. It stores the entire database in a single (flat) file. SQLite is in many instances more efficient than running running daemons such as MySQL, Oracle or PostgreSQL. It's used by Firefox, iPhone, Skype and Trac just to name a few. Your sig says you're using Mac OS X, so it's already on your computer.

 

Before everybody starts dropping their RDBMS in favour of SQLite....

 

It should be noted that although efficient in the right application, SQLite doesn't scale too well. Tbh, I'm a bit surprised that Trac uses SQLite. I assume it's optional.

 

Also, SQLite does not fall in the ' flat-file database'-category. It is a relational database system. The fact that it uses a single file for storage instead of many does not change that.

 

SQLite is not build for high concurrency. It locks the entire db file. This isn't an issue for most applications, especially desktop applications like the ones in your list, but in applications with potentially high concurrency (such as these forums), it should be avoided IMHO.

 

Check out this link, which gives some indication of how locking of the db file is going to affect concurrency:

 

http://www.sqlite.org/lockingv3.html#writer_starvation

 

 

 

 

[448191 25]

Hmm.. It would seem Wikipedia thinks I'm wrong about this bit:

 

Also, SQLite does not fall in the ' flat-file database'-category. It is a relational database system. The fact that it uses a single file for storage instead of many does not change that.

 

Practical implementations

 

    * Berkeley DB, a robust flat file database for critical applications which does ACID.

    * TextDB, a file-based database designed to handle high loads.

    * SQLite, a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine.

    * Mimesis, an ffdb that uses multiple files and folders in order to increase the reliability of atomic updates.

 

 

[jcombs_31 0]

I really think a flat file should only be used for something like a configuration file.  It doesn't make any sense to store data in a flat file.

[947740 0]

To me, everything would be easier with a database.  You can make scripts to edit the news stories, add news stories, delete news stories, etc.  Sure, you can do that with a flat file, but it would be (I think) harder.  It just seems that MySQL and other relational database systems would be better for that application.

[dare87 0]

MySQL all the way!

[Darklink 0]

You can't vote which ones better! They depend on what you want to do.

 

Using a flat-file system you can generate a cache (little to none resources needed), whilst using SQL will require resources. However SQL is incredibly useful when you want to find, update, join and delete data quickly.

 

I would never recommend on creating a flat-file database, but rather a datastore which is used to simply cache small sets of data if needed.