Register for your free account! | Forgot your password?

You last visited: Today at 18:00

  • Please register to post and access all features, it's quick, easy and FREE!

Advertisement



flat file or database

Discussion on flat file or database within the CO2 Private Server forum part of the Conquer Online 2 category.

Reply
 
Old   #1
 
LordGragen.'s Avatar
 
elite*gold: 0
Join Date: Dec 2012
Posts: 606
Received Thanks: 68
flat file or database

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



allot of them said MSQL

but i am thinking why did Hybird made his source on flat file. its interesting.
LordGragen. is offline  
Old 05/28/2013, 23:32   #2
 
elite*gold: 0
Join Date: May 2013
Posts: 6
Received Thanks: 1
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.
Hex* is offline  
Old 05/28/2013, 23:37   #3
 
Super Aids's Avatar
 
elite*gold: 0
Join Date: Dec 2012
Posts: 1,761
Received Thanks: 950
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.
Super Aids is offline  
Old 05/29/2013, 00:52   #4


 
CptSky's Avatar
 
elite*gold: 0
Join Date: Jan 2008
Posts: 1,443
Received Thanks: 1,175
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 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 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.
CptSky is offline  
Thanks
2 Users
Old 05/29/2013, 03:30   #5
 
InfamousNoone's Avatar
 
elite*gold: 20
Join Date: Jan 2008
Posts: 2,012
Received Thanks: 2,885
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



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.
InfamousNoone is offline  
Thanks
1 User
Old 05/29/2013, 10:02   #6
 
LordGragen.'s Avatar
 
elite*gold: 0
Join Date: Dec 2012
Posts: 606
Received Thanks: 68
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.
LordGragen. is offline  
Old 05/29/2013, 11:32   #7
 
Super Aids's Avatar
 
elite*gold: 0
Join Date: Dec 2012
Posts: 1,761
Received Thanks: 950
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.
Super Aids is offline  
Reply


Similar Threads Similar Threads
Converting flat-file to MySQL (ini to MySQL) - How?
09/13/2011 - CO2 Programming - 3 Replies
The question says it all. Using LOTF is a real joy for me because I understand it real well. The only problem is I like to use my PHP skills and I don't know/think I can have it read data like it would from a MySQL database by using .ini databases. How would I go about re-writing the database to save/load by using MySQL? Is it as simple as copying another sources way of save/loading?
Database vs. Flat-Files
04/08/2010 - CO2 Programming - 21 Replies
Post your opinion.
Editing a flat-file or ini source
01/31/2009 - CO2 Private Server - 4 Replies
The v1.3 ShadeCO source is an example, how do you modify these, like adding coding that normal is done on C# files
Keving's Flat-File DB makes Inventory Bug!!
11/18/2008 - CO2 Private Server - 13 Replies
Just to warn peoples ... if you use Keving's Flat-File Database , it makes Inventory bug... After 14 items in inventory and if u dc and re login char is naked and not all items in inventory appears!



All times are GMT +1. The time now is 18:02.


Powered by vBulletin®
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Support | Contact Us | FAQ | Advertising | Privacy Policy | Terms of Service | Abuse
Copyright ©2025 elitepvpers All Rights Reserved.