Thread: file system vs sql database

well, database is not really my strong field. But, as i understand ( i might be wrong ), system would be faster compare to using database, because of all the connection process with the database.

Good database technique is: Open the connection, get data, store in a buffer, then close the connection. That would take more time. Trust me, i did that to my final project, and the project runs extremely slow everytime I process a function that involving getting data from database.

The rest of your question, i'll save it for some other expertises.

Well what else are you going to use the program for?

If it's just a simple homework, with a console/GUI interface, then perhaps a file approach.

But if someone might ask later on, "can we have a web interface", then having it all in SQL will make that change exceedingly easy.

> all I'll be doing is just "select entry where index = X" or something like that..
If there is any inclination to expand on that in the future, then perhaps it's a good choice now.

We need more background info to make better suggestions.

Personally, I think I'd go the mysql route.

It's all ready set up with things like being able to cope with distributed web access, and has already solved the concurrency problems.

Adding more data, more users, more inquiries etc will be a lot easier in future. All of which would potentially require lots of code on your part.

Also, for a web-facing application, the security requirements are not to be under estimated.
http://en.wikipedia.org/wiki/Sql_injection

Making your C++ application proof against buffer overrun, memory leaks, etc etc will be no small feat in itself.

Originally Posted by underthesun

I will have millions of record, and each have relations to around 6ish other records. Each of these records would be around 200 bytes or less.. and they'll only ever be accessed by an index number (which is a long).

The question is, would it be better to store these under sql, or would it be better to just store these under the file system, with the file names as their indexes? If I use SQL, all I'll be doing is just "select entry where index = X" or something like that..

What, you're telling us that you have millions of records and you never plan to insert more or update existing records?

Oh, you do plan to do that? Well, do you ever plan on maybe, just maybe, having more than one person to be able to add or edit records at once, or one person updating and another person reading? Might you also want to someday be able to give some people different access such as read-only to the data? Is it possible that you might at some point want to perform some updates in a transactional manner? Do you want to be sure that you'll never have records that refer to invalid record indexes? What about other one-off values that you might otherwise have to store seperately in the registry or an ini file (requiring seperate backing up), as opposed to in a seperate table of special values?

It seems to me like you should future proof this now and use a database like everybody else.