Hey, I've been wondering which is better for moderately small web-based projects: an SQL database or just a text file. It really isn't that hard to write a couple classes that edit and read files. Heck, they can be decrypted if the data is sensitive. There are several factors to consider, of course: 1. Portability. I'd say that text files are far more portable as you can just copy+paste. 2. Speed. Not sure about which can be loaded faster. 3. Security. I guess you don't have to worry about database login information with text files and encryption can be applied to text files with sensitive data. However there are plenty of vulnerabilities I'm sure I'm not aware with with both. 4. Ease. Databases would probably be easier, as you wouldn't have to worry about data formatting as much. What do y'all think? I've always wondering if databases are a bit over kill for small amounts of data being stored. I can imagine it being necessary for something big like a forum or CMS, though.
I'm not necessarily talking about very large systems. However, it isn't too hard to lay out text files in a logical manner. You could have several data directories with .dat files with logical names. You could mimic the layout of a table with rows separated by "\n" and columns separated by " ". If you know what you're doing, then I don't see why complexity is an issue. Tables in SQL can look pretty cluttered to if you do it lousily.
Well i remember i use to work with a flat file file uploading system before which runned only 1 text file the issues starting coming up where due to large amount of data writing it use to get conflicted and get empty...
Interesting. Do you mean when you wrote a ton of data to the file at once or when it got huge from a lot of data being written to the file over a fairly long period of time? What were you storing in the file exactly?
See basically the script use to write to one single file so since it was a user based uploading site it use to get buged if multiple uploads happened at exact same time which caused issues the only thing written to that file was details of the file like description, ip of the uploadeders, password if any
Ah, I see. The files were corrupted by multiple processes doing something to it at the same time. I guess you could avoid that by having a caching system. You'd write each to an individual, uniquely-named, file in a temporary directory then have a daily process to write them all to the permanent storage location. However, I guess that is a bit over-complicated.
Well then what we just did was get an inividual file for each file eventually we shifted to mysql it helps in keeping a lot mess clean
I'll fill that in. The speed of flat file systems depends on your technique. Generally, for a small amount of data, a flat file system would be faster if built with speed in mind. For many, their SQL server is on another domain. That means time must be taken to look up the domain and/or connect to it. SQL also usually requires some form of authentication which, although short, takes some time of its own. Flat file systems, however, tend to be on the same server, and usually do not require any authentication other then OS operations. This is one of the reasons why many web developers use file caching when applicable. Yes, they use it to avoid repeating processing/calculations, but they also use it because access time for flat files are quicker.
Most people use databases because they were told they're supposed to by people who don't know the reason for doing so. Plain text is a common way of storing settings and information in *nix. The reason is it's easy for humans to read, easier to manipulate and faster. Plain text is all that most people need and is frequently the best way. Those who need databases are those who need to manipulate various types of data and how they all relate to each other. How many widgets were sold in one category compared to another category and price, for example. A flat file can do that, too, but if the queries change often, databases can make it easier.
I would put it this way. Both solutions have their pros & cons, and it purely depends on application requirements which storage media to choose. If I have to only dump data which does not need to be retrieved frequently for reports, I put it in files. If search functionality is needed, I better use database. If small data set needs to be read very frequently, I better put it in file. Likewise, there would be more factors to be considered and thought of for deciding storage medium. It also depends on application to application and person to person.
2. Speed - database will be much faster since it uses a special method just for searching 3. Security - i would go for database more secure and easy to setup 4. Ease - database by far database won big time (file system is the old school)
I've always suspected as such. Makes sense. Yeah, I see what you mean about people being told to use SQL as opposed to flat file. It seems that this is really dependant on how you learn to program, to my perception. The tutorial sites for web development will teach you databases, period. However, if you start from desktop programming, such as most C++ courses, then you will end up learning file manipulation techniques. I guess it's tempting for a web developer who doesn't do any other kind of programming to use SQL because you don't have to design your data storage structure. What do you mean? Essentially, a database has to store data in files too. The data just isn't visible. What do you mean by more secure? You havwe to have a database password to connect. A file system does not have authentication so you don't have to have that extra password, which is a venerability. Programming isn't supposed to be easy. May I ask how much / what experience you have in programming, animebuzz.tv? Just curious.
Programming IS supposed to be easy. Just because it 's hard for you, it does not mean it 's hard for everyone. OMG. Btw, PHP 5 has SQLite support by default. SQLite is serverless, file-based db. Why would you go and reinvent the whell, introduce 43289498 bugs when it already exists optimized?
Why do you think that? Programming can be easy, but that is not central to its purpose. Programming is supposed to be practical and then, if possible, easy. A programmer that sacrifices quality for ease will never match the competition. What's hard for me? MySQL stores its data in files too. That's how all computer data is stored. I can imagine it being serverless being a very good thing, though. What's a whell? Because not all tasks require a fancy database. Sure, a hummer is faster and more powerful than an economy streetcar but it's also a gas-guzzler which the average person can't afford to drive around. The same applies to data storage. As we've discussed on this thread, databases and files both have their own specific situations they fit. May I ask how much experience you have in programming? My guess is that you havce never worked with files before, but I could be wrong.