Wheel, incorrectly spelled. I 've been coding for $ in PHP since early 2000. Now that that 's out of the way, let me address your arguments. A database is a specialized instrument for efficient retrieval of structured information. I suppose we agree on that. What you say is, "my project is small, f*ck the db, I 'll do it manually using a text file". Ok, that 's cool, we create programs any way we like. I also suppose we agree that if a project is not that small, it is better to use a db. What is say is that if the project involves any storage/retrieval of structured information, even a login system, it 's better practice to use a db system. Why? You might expand the project later on for another client and actually need a lot more storage/retrieval and have to refactor Almost every host has MySQL support already and in the rare case that it does not, there are sites that give free MySQL databases. File handling problems that occur. What happens if two instances of your script try to write at the same time on the same file? You 'll have to implement a file locking mechanism -> more complexity. What if your script is run on Windows server? File locking for PHP has problems on Windows, you 'll need to write even more code --> more complexity. What if the user deletes or edits the file manually? This is easier to happen that the user to manually edit a database.
I have no idea what you just said. Good. I made a poor judgement on your age based on the grammar you used in your post. Usually when people use "OMG" at the end of a sentence they are below the age of 13. No offense. Correct. Specifically I created the thread to discuss the difference in speed and security between databases and text files for non-gigantic projects. I'm not actually working on a specific project at the moment. However, I find that there's a decent bit of bias towards databases in some of the shorter replies on the thread, as web developers ar enever taught to manipulate text files. Text files and databases are compatible. You can store some data through one method and some data through another. Sure, but the consensus on this thread seems to be that text files are faster for some (minimalistic) forms of data. (you can disagree if you like, but until then I'm assuming it is) Yeah, discussed a couple posts back. There are still ways around it. I'd never use a windows sever for PHP. Not really. An idiot can screw things up using phpmyadmin but you have to know the directory structure to know which files to edit in a file based system. Anyway you can make files invisible by prefixing the name of a folder with a "." character.
The thing is you need to dump your old code and migrate the functionality to use a db. Why not do it from the start? Imagine scenario 1: Program A Open a 10MB file, ready it in memory, create an MD5 hash, exit Program B Connect to the db, query 10MB of data on 1 query, create the hash, exit Probably A will be faster. (I did not test, I suppose) In scenario 2: Now consider a big web shop, like a small amazon. DB is absolutely necessary, I think we agree here. Finally: So, what we are actually both saying is that there is a point between scenarios 1 and 2 that DB wins over text files custom handling data. I am saying this point is closer to scenario 1 than to scenario 2. You put the point further away from scenario 1. To actually find the answer, we need to create two mockup test apps and do some benchmarking.
As sites grow larger they require the system to be streamlined to fit its current needs. If a website exists for 6 years, 3 of which it's small enough to use text files and 3 years in which it's too big, I don't see why adapting a couple months ahead of year 4 is a problem. The transition should be fairly simple if you keep your data-opening code into its own class. you'd just have to rewrite part of the class and write a program to read the file and run queries to put it into the database.
The size of the project has nothing to do with whether a database or flat file is needed. It's the data and how it is used that determines this. To use a database "just because" or "what if" is pure nonsense. A large restaurant chain you know of uses online ordering for thousands of customers and does not use a database. I know. I wrote it. I didn't have to worry about whether the server had the db software installed. It runs everywhere. It's smaller and easier to understand, edit, fix, retrieve the data if needed. And no SQL language was needed to learn, understand or interface with.