[Unkovic]

Title says all. Write comments

[Graber]

oh no...

[Freaksken]

You shouldn't compare the 2, because they serve different purposes.
.ini stands for initialisation. In other words, only use it for that (like loading settings for a minigame on startup). For anything else, use SQL.

This question has been asked time and time again. Use the right tool for the right job.

[Unkovic]

Quote:

Originally Posted by AmigaBlizzard Speed isn't the only thing you should look at. It's the same with cars. Everyone wants to have a fast car like a Ferrari or Porsche, I don't. You're not allowed to drive that fast anyways and such cars usually have a very small trunk to put some stuff. When you go somewhere and want to buy a big tv or a fridge, you won't get it inside your fast and expensive car. You have to pay extra to get it delivered to your house and you probably have to take a day off from work on the day of delivery. I can just load it up with my Kangoo. I like space and flexibility, not speed. Inserting things in a database table takes longer than simply writing a new textfile, but you also have the flexibility to take into account. Let's say you have already a thousand players and you've written your server to use ini-files for your player's data. And at some point you want players to check who's the richest player. Using ini-files, where you save a player's data, including his money, into his own account-file, you would need to open ALL those player-files, read everything to find the money-value in that file, close the file and move on to the next one, while remembering the richest player's name and money. I can tell you that opening a thousand files everytime a player wants to check who's the richest player, it WILL give lag on your server and some might even try to crash your server by using that command as fast as they can, or at least make the server unplayable for everyone else. You could of course have a separate file which holds the name and value of the richest player if you implemented that feature from the start and overwrite it everytime some player becomes richer than the player saved in that file. But that won't do you much good when you implement it later. Even if you have thought of richest player and you want a similar feature like highest score, you can start all over again, reading all files, finding the player with highest score and make a new file to remember the player with highest score and edit your score-giving functions to overwrite the file when someone gets a even higher score. With a database, it's simply a matter of adding the proper query as the data is all in the database already. And using a database, you can use threaded queries which won't lag your server. And when you're using SQL, I suggest going to full MySQL altogether. The query structure stays the same anyways so it isn't harder to learn. You gain the benefit of using threaded queries. AFAIK (I might be wrong though as I never used SQLite), SQLite doesn't have threading so when you have a large database, you might experience some lag using SQLite. If you have a simple server without such features, you might find ini-files good enough for the job. I also liked INI files more than MySQL, but since I've learned to use MySQL, I'm never going back to files, even for simple scripts. And I ran a test in speed comparing files and a database. I found that writing my playerfile 1000 times in a row was still faster than inserting 1 new row in the database. But I still prefer flexibility over speed. And btw, speed doesn't matter because with MySQL, you will be using threaded queries so they run in the background and won't stall your server for the duration of the query, unlike files and SQLite as well.

Quote:

Originally Posted by Freaksken You shouldn't compare the 2, because they serve different purposes. .ini stands for initialisation. In other words, only use it for that (like loading settings for a minigame on startup). For anything else, use SQL. This question has been asked time and time again. Use the right tool for the right job.

I asked because i need to make include with saving, so, i need some of this 2 (sqlite, dini2) because someone doesnt know how to establish connection with mysql

[Unkovic]

Quote:

Originally Posted by Y_Less So you picked the worst DB system and the worst INI system?

So master? What is the best INI system, lord?

Quote:

Originally Posted by Y_Less Then learn...

If i say someone, i mean someone, not me.

[PrivatioBoni]

Quote:

Originally Posted by Unkovic So master? What is the best INI system, lord? If i say someone, i mean someone, not me.

Your attitude is horrific.

[Unkovic]

Quote:

Originally Posted by PrivatioBoni Your attitude is horrific.

Thanks.

[Unkovic]

Quote:

Originally Posted by Y_Less Well I'd say y_ini, since it is the fastest and has the most features. Why does what other people are able to use matter to which you should use?

Why you say Y_Ini every time?

Idk, i don't know how to code mysql saving in include, because someone who will use include, won't know how to establish connection.

Im planned ti have 2 savings, and if people #define mysql parameters and mysql saving, then save in mysql, else, in ini

[Y_Less]

Why would I change what I said? The best doesn't really change every time you ask.

[Freaksken]

Quote:

Originally Posted by Unkovic Why you say Y_Ini every time?

Because benchmarks.

[Y_Less]

Quote:

Originally Posted by Unkovic Why you say Y_Ini every time? Idk, i don't know how to code mysql saving in include, because someone who will use include, won't know how to establish connection. Im planned ti have 2 savings, and if people #define mysql parameters and mysql saving, then save in mysql, else, in ini

I'm slightly confused now. Do you not know, or do your users not know? If you don't know, then as I said earlier, learn. If your users don't know, so what? The point of writing libraries is to abstract details like this away. You put the SQL in your include, then users don't need to learn it.

And giving them options like that is just doubling your work for no real reason.

[Mike861]

Quote:

Originally Posted by Unkovic Why you say Y_Ini every time? Idk, i don't know how to code mysql saving in include, because someone who will use include, won't know how to establish connection. Im planned ti have 2 savings, and if people #define mysql parameters and mysql saving, then save in mysql, else, in ini

He's not only saying y_ini because its from his YSI package, but because y_ini is really the only INI system you should use nowadays, no matter if there's dini improved version.I wanted to learn MySQL myself but since im lacking with time i decided to use y_ini and will try other stuff from the YSI package since i never did.

[Unkovic]

Quote:

Originally Posted by Y_Less I'm slightly confused now. Do you not know, or do your users not know? If you don't know, then as I said earlier, learn. If your users don't know, so what? The point of writing libraries is to abstract details like this away. You put the SQL in your include, then users don't need to learn it. And giving them options like that is just doubling your work for no real reason.

Users.

You are confusing me now. I don't know what you want to say by this

Quote:

Originally Posted by Y_Less If your users don't know, so what? The point of writing libraries is to abstract details like this away. You put the SQL in your include, then users don't need to learn it. And giving them options like that is just doubling your work for no real reason.

[Unkovic]

Quote:

Originally Posted by Mike861 He's not only saying y_ini because its from his YSI package, but because y_ini is really the only INI system you should use nowadays, no matter if there's dini improved version.I wanted to learn MySQL myself but since im lacking with time i decided to use y_ini and will try other stuff from the YSI package since i never did.

nek si mi rekao xD

[Y_Less]

I meant, it doesn't matter if your users don't know SQL, since you (sound like you) are writing a library to hide those details.

[Unkovic]

Quote:

Originally Posted by Y_Less I meant, it doesn't matter if your users don't know SQL, since you (sound like you) are writing a library to hide those details.

btw, they will need connection part. Table creation (which can be created through inc, but.. huh). That is only problem.

I don't have too long discussions while ago, until this. I like this.

[iKarim]

Quote:

Originally Posted by Unkovic btw, they will need connection part. Table creation (which can be created through inc, but.. huh). That is only problem. I don't have too long discussions while ago, until this. I like this.

Are you sure you're on the right forum? Most of the people here know how to setup a MySQL server except those few have 2 digit IQ --you may be one of them-- and I doubt your capability of writing a library judging by your recent posts.

[Kar]

I'm not even gonna read the comments.

You can't compare the 2.

Also those are a really bad 2 to compare. lol

[Y_Less]

Quote:

Originally Posted by iKarim Are you sure you're on the right forum? Most of the people here know how to setup a MySQL server except those few have 2 digit IQ --you may be one of them-- and I doubt your capability of writing a library judging by your recent posts.

IQ and knowledge aren't the same thing. You can be very smart, but if you've never been told something, then it doesn't matter how smart you are - you won't know it.

[GhostHacker9]

Quote:

Originally Posted by Y_Less IQ and knowledge aren't the same thing. You can be very smart, but if you've never been told something, then it doesn't matter how smart you are - you won't know it.

whoosh!