flat file or database

05/28/2013 23:11 LordGragen.#1
i was searching on google today about which is better to use,

flat file or database. i found few good answers about database is more faster and stuff but some also said flat file is good to.

can anyone explain me which will be good to keep?
lets say i have 450 members onlne

will flat file be my best option or MSQL

[Only registered and activated users can see links. Click Here To Register...]

allot of them said MSQL

but i am thinking why did Hybird made his source on flat file. its interesting.
05/28/2013 23:32 Hex*#2
Flat-file for small projects, database for big projects (a public released server). Flat-file isn't efficient with big projects as far as I know. Anyhow, I'd choose database.
05/28/2013 23:37 Super Aids#3
Thread-safety is much harder to achieve proper with flatfiles (I assume you're referring to the winapi calls Kernel32.WritePrivateProfileString and Kernel32.ReadPrivateProfileString etc. and they aren't thread-safe.)

That being said. It is faster at some points, however it's not suited for a database and if you want proper database management then using sql would be far the best. There is a reason why it was made. At other points sql is also faster than flatfile, at it may handle the data better as well.

That being said, handling sql wrong can become a huge issue as well.

In the end using sql would be a better choice and especially when you're going to have a lot of connections since flat-file databases could end up with IO-issues. Such as writing to an already open file, that has not yet been close. You can achieve thread-safety for it though, but I'm not sure if it would be worth it.

Now what about management etc. it's far easier to manage data using sql because of all the database-management programs ex. Navicat, Microsoft Sql Management Studio etc.

Also sql would have a significant larger amount of features than flat-file databases would have. Talking about primary keys, incrementing, table-relations etc. these are things that aren't really possible in flat-file, however you can "manipulate" something similar by filenames being row, folders being primarykeys, tables etc. but in the end the datatransfer wouldn't be as fast as sql.

If you're going to read/write to a lot of files VS reading/writing a lot of data to an sql database then the sql execution would probably faster than the file-IO execution.

I can come up with an example. In ProjectX V3's source (The one I released not too long ago.)
I was using flat-file in that for the database and the items (was storing each item in a file for them self.) took very long to load, however when I switched to sql the loading was incredible fast.
05/29/2013 00:52 CptSky#4
Quote:
Originally Posted by Super Aids View Post
Thread-safety is much harder to achieve proper with flatfiles (I assume you're referring to the winapi calls Kernel32.WritePrivateProfileString and Kernel32.ReadPrivateProfileString etc. and they aren't thread-safe.)[...]
The sh*tiest method to use in a database :rolleyes: It will reloads the file FOR EACH read, which is pretty slow. Those methods are here to work in the registry, not with INI, so if you ever INI for big task, use a real INI lib.

Quote:
Originally Posted by Super Aids View Post
[...]I was using flat-file in that for the database and the items (was storing each item in a file for them self.) took very long to load, however when I switched to sql the loading was incredible fast.
Did the same in COPS v6, until I decided to go binary :p I had a 100 MB items.pkg which could contains approximately 1M items. It was really fast, and pretty easy to manage. But nothing compared to a real database. (Just had to seed to the (UID * sizeof(ItemInfo)) and check for a byte).

N.B. I had a separate thread for the saving I/O in the file...


A database is almost always better for a server. I almost always used flat-files due to the cheap hosting I had, which wasn't really great when using a MySQL database. Well, at the end, I was using a lot of optimized binary files for the static database and packages/XML for the dynamic database. The performance was okay, but the thread-safety was terrible. Today, if I had the same restriction (no SQL server), I would go for SQLite. The performances aren't similar to MySQL (or MsSQL that I never used), but it doesn't require an external server and the library is really small.
05/29/2013 03:30 InfamousNoone#5
Quote:
Originally Posted by LordGragen. View Post
i was searching on google today about which is better to use,

flat file or database. i found few good answers about database is more faster and stuff but some also said flat file is good to.

can anyone explain me which will be good to keep?
lets say i have 450 members onlne

will flat file be my best option or MSQL

[Only registered and activated users can see links. Click Here To Register...]

allot of them said MSQL

but i am thinking why did Hybird made his source on flat file. its interesting.
only because flat file portability is so much easier than asking anyone setting up your server to install my/mssql, understand how to use it, understand the tools that go with it, etc.
05/29/2013 10:02 LordGragen.#6
Quote:
Originally Posted by InfamousNoone View Post
only because flat file portability is so much easier than asking anyone setting up your server to install my/mssql, understand how to use it, understand the tools that go with it, etc.
oh okay coz i was making a another simple project on that source and i was wondering to keep flat or change it msql but i will change to to msql later on.
05/29/2013 11:32 Super Aids#7
If you plan to change it in the future from flatfile to sql then I want to suggest you make it very dynamic. Otherwise you'll have a hard time switching over, because you will end up correcting too many errors. That was my mistake when I switched over.