views:

469

answers:

7

I'm creating and app that will rely on a database, and I have all intention on using a flat file db, is there any serious reasons to stay away from this?

I'm using mimesis (http://mimesis.110mb.com) it's simpler than using mySQL, which I have to admit I have little experience with. I'm wondering about the security of the db. but the files are stored as php and it seems to be a solid database solution.

I really like the ease of backing up and transporting the databases, which I have found harder with mySQL. I see that everyone seems to prefer the mySQL way - and it likely is faster when it comes to queries but other than that is there any reason to stay away from flat-file dbs and (finally) properly learn mysql ?


edit Just to let people know, I ended up going with mySQL, and am using the CodeIgniter framework. Still like the flat file db, but have now realized that it's way more complex for this project than necessary.

+3  A: 

Use SQLite, you get a database with many SQL features and yet it's only a single file.

Lukáš Lalinský
cauko,I've came across this solution(http://www.sqlite.org/) few times. Am I looking at the wrong website or missing something? It seems like I need to have it set up with the host, which might make deploying this harder than mySQL
Daniel
The host needs to have SQLite installed, but many hosts have that as a default these days. If it's installed, the host doesn't have to do anything for you to use it.
ceejayoz
No, you point it to a file and it will use only that file (create if it doesn't exist). After that you use it as a regular relational database, that is create tables with `CREATE TABLE`, insert data with `INSERT`, etc. See the docs for some examples - http://www.php.net/manual/en/function.sqlite-open.php
Lukáš Lalinský
A: 

Interoperability. MySQL can be interfaced by basically any language that counts. Mimesis is unlikely to be usable outside PHP.

This becomes significant the moment you try to use profilers, or modify data from the outside.

Martin Hohenberg
+1  A: 

The answer is "Fine" if you only NEED a flat-file structure. One test: Would a single simple spreadsheet handle all needs? If not, you need a relational structure, not a flat file.

If you're not sure, perhaps you can start flat-file. SQLite is a great app for getting started.

It's not good to learn you made the wrong choice, if you figure it out too far along in the process. But if you understand the importance of a relational structure, and upsize early on if needed, then you are fine.

Smandoli
relational structure - that's a great consideration.I'm planning one master table with other table names inside the rows so for this purpose it will suffice, but I that's a good limitation to be aware of - thanks
Daniel
Hmm! That sounds like you are going to some lengths to model a relational database using a flat file app. I'd be worried if that's the case.
Smandoli
Basically, you DESERVE to learn MySQL. Portability and Back-up are prolly simpler than you estimate. I use good ol' phpMyAdmin, and I've successfully restored. Have not tried porting over to another site. Making back-ups is extremely fast and simple. My question is, do you have a test web server (LAMP/WAMP)? If you lack this, and a decent IDE, then any learning and experimentation will feel burdensome.
Smandoli
A: 

You might also look at http://lukeplant.me.uk/resources/flatfile/ for the PHP Flatfile Package.

meme
haven't heard of this one yet, might be worth comparing to mimesis, Thanks
Daniel
+1  A: 

I really like the ease of backing up and transporting the databases, which I have found harder with mySQL.

Use SQLite as mentioned in another answer. There is only one file to backup, or set up periodic dumps of the MySQL databases to SQL files. This is a relatively simple thing to do.

I see that everyone seems to prefer the mySQL way - and it likely is faster when it comes to queries

Speed is definitely a consideration. Databases tend to be a lot faster, because the data is organized better.

other than that is there any reason to stay away from flat-file dbs and (finally) properly learn mysql ?

There sure are plenty of reasons to use a database solution, but there are arguments to be made for flat files. It is always good to learn things other than what you "usually" use. Most decisions depend on the application. How many concurrent users are you going to have? Do you need transaction support?

Buggabill
A: 

The issue with going flatfile is that in order to adjust the situation for further development you have to alter a significant amount of code in order to improve the foundation of the system. Whereas if it was a pure SQL system it would require little to no modification to proceed in the future.

Webnet
+1  A: 

Greetings, I'm the creator of Mimesis. Relational databases and SQL are important in situations where you have massive amounts of data that needs to be handled. Are flat files superior to relation databases? Well, you could ask Google, as their entire archiving system works with flat files, and its the most popular search engine on Earth. Does Mimesis compare to their system? Likely not.

Mimesis was created to solve a particular niche problem. I only use free websites for my online endeavors. Plenty of free sites offer the ability to use PHP. However, they don't provide free SQL database access. Therefore, I needed to create a database that would store data, implement locking, and work around file permissions. These were the primary design parameters of Mimesis, and it succeeds on all of those.

If you need an idea of Mimesis's speed, if you navigate to the first page it will tell you what country you're viewing the site from. This free database is taken from the site ip2nation.com and ported into a Mimesis ffdb. It has hundreds if not thousands of entries.

Furthermore, the hit counter on the main page has already tracked over 7000 visitors. These are UNIQUE visits, which means that the script has to search the database to see if the IP address that's visiting already exists, and also performs a count of the total IPs.

If you've noticed the main page loads up pretty quickly and it has two fairly intensive Mimesis database scripts running on the backend. The way Mimesis stores data is done to speed up read and write procedures and also translation procedures. Most ffdb example scripts or other ffdb scripts out there use a simple CVS file or other some such structure for storing data. Mimesis actually interprets binary data at some levels to augment its functionality. Mimesis is somewhat of a hybrid between a flat file database and a relational database.

Most other ffdb scripts involve rewriting the COMPLETE file every time an update is made. Mimesis does not do this, it rewrites only the structural file and updates the actual row contents. So that even if an error does occur you only lose new data that's added, not any of the older data. Mimesis also maintains its history. Unless the table is refreshed the data that rows had previously is still contained within.

I could keep going on about all the features, but this isn't intended as a "Mimesis is the greatest database ever" rant. Moreso, its intended to open people's eyes to the fact that SQL isn't the ONLY technology available, and that flat files, when given proper development paradigms are superior to a relational database, taking into account they are more specialized.

Long live flat files and the coders who brave the headaches that follow.

Grim Pirate
Hey, good to see the creator's comments! I was wondering if you had any recommendations on how to integrate multiple tables to act almost as a relation database? Though I realize that that's not the point of it, there is room to build a relational database on top of mimesis, no?
Daniel
Absolutely Daniel. It would take some creative thought but its not impossible. In Mimesis rows are given labels to distinguish them from one another. These row labels are similar to a primary key. By utilizing a clever labeling scheme across tables you could create references between them. The only operation that Mimesis does not support (at least not well) is insertion/deletion of columns. In those cases it becomes necessary to rewrite the whole database. Its my opinion though that columnar insertion/deletion is unnecessary if you think well about what your table will need beforehand.
Grim Pirate