SQL Support

[Xero_]

Hello.

I'm not very experienced in the Eclipse engine. I noticed that it records the players on the disk trough .ini files. For some thousands of accounts that's ok. But when it reaches millions it can be a problem.
My question is: does Eclipse support SQL (any database, MySql would be great)? There are plans for that support on the future?

Thanks.

[Robin]

Latest version uses binary.

[Ispan]

@Xero_:

> For some thousands of accounts that's ok. But when it reaches **millions** it can be a problem.

Show me a single Mirage based game that has ended up getting anything close to a million players.

[Robin]

I'm more interested in why a million accounts is a problem at all.

They're simply data storage. You're only limited by your HDD space.

[BK201]

I realise this is an old thread but I'd rather make a comment on this one instead of starting a new thread.  SQL is still far more efficient, but the biggest thing that would be gained from the switch is being able to execute queries. Say, you wanted players to have a id for a farming skill, but your current 2000 players don't have that in the files and any scripts calling those values are going to generate errors. While with SQL you could update the entire database incredibly efficiently and simply. Granted, I'm not saying there isn't other ways to solve the problem. But SQL is for more simple and efficient imagine if you need to update or create a lot of new values on a lot of players or players with a certain value in a certain field.

[Godlord]

@BK201:

> I realise this is an old thread but I'd rather make a comment on this one instead of starting a new thread.  SQL is still far more efficient, but the biggest thing that would be gained from the switch is being able to execute queries. Say, you wanted players to have a id for a farming skill, but your current 2000 players don't have that in the files and any scripts calling those values are going to generate errors. While with SQL you could update the entire database incredibly efficiently and simply. Granted, I'm not saying there isn't other ways to solve the problem. But SQL is for more simple and efficient imagine if you need to update or create a lot of new values on a lot of players or players with a certain value in a certain field.

Using memory-mapped files locally is faster than using a SQL database. The only reason to use database servers, is when you have a cluster of computers that have to operate on a single, but large dataset.

Yours faithfully
  Stephan.

[BK201]

How is it more efficient, having 2000 player files separated.  Whereas you could have them all in a database. Like i was saying earlier what if you wanted to make changes to a large amount of players. Or say, you wanted to have a high scores page on a website. Currently you'd have to run through all the separate files, like the high scores example you would have to run through all the files constantly or a set period. Whereas using something like MySQL you could have it in real-time consuming almost no resources? Just being able to execute queries would make it a better option imo.

[Wing]

With a database you would have to maintain the connection of the database with the server, but without it you can localize all your files.

A database is where you keep everything if its distributed among different computers.

[BK201]

@♥:

> With a database you would have to maintain the connection of the database with the server, but without it you can localize all your files.
>
> A database is where you keep everything if its distributed among different computers.

Why's that a bad thing. If you didn't want to connect to a web server you could use SQLite for example.

[Wing]

Its bad because its slower. Unless you need multiple servers to connect to the same database there is no point.

[BK201]

It's not slower, it's faster. Lets stick with 2000 for example purposes. In some instances the server is running through 2000 files, and all the data in those files. Lets user a real world example, you have 2000 contact files you need to find all names that have one of three phone numbers and organize them. So you can't use the index numbers at the top, those aren't related to phone numbers so you have to go through all the files, and every line in them MANUALY. Now what if you had something in your brain that would spit out the data your requesting. Which is easier on your brain? server connects to database -> executes query -> a database administration program handles the query (MySQL, SQLite) -> returns the data to the server. Which is more efficient?

[BK201]

OK  in terms of efficiency it's not better here. I wasn't paying attention to what SJR.  Blah I'm sorry. Though, you still have the advantage of queries, running a wesbite.

Sorry for the double post.

[BK201]

@BK201:

> OK  in terms of efficiency it's not better here. I wasn't paying attention to what SJR.  Blah I'm sorry. Though, you still have the advantage of queries,  running a wesbite.
>
> Sorry for the double post.

[Scott]

@BK201:

> OK  in terms of efficiency it's not better here. I wasn't paying attention to what SJR.  Blah I'm sorry. Though, you still have the advantage of queries, running a wesbite.
>
> Sorry for the triple post.

It is a nice tool to have, but only if your going to use it.  If you want a website/forum login to be integrated or some sort of high scores its a great idea, otherwise its a waste.  Not to mention you need to host that mysql database on a server that will let you install the files you need to let vb6 connect to it.  Than on top of that you need to set up a login server to handle logins because the mysql connection can lag the server loop a ton.

[BK201]

Well a lot of what you said is incorrect but it's w/e, I don't wanna explain anymore  :P. My main point is wrong because I thought the server was parsing text files. I'm a newbie myself not ready to teach anyone or go really in-depth about shit.

[BK201]

@BK201:

> Well a lot of what you said is incorrect but it's w/e, I don't wanna explain anymore  :P. My main point is wrong because I thought the server was parsing text files. But why would you have a game without a functional website  :confused:.

omfg I keep hitting quote instead of edit.

[Wing]

@BK201:

> OK  in terms of efficiency it's not better here. I wasn't paying attention to what SJR.  Blah I'm sorry. Though, you still have the advantage of queries, running a wesbite.
>
> Sorry for the double post.

This is true.

[Robin]

@BK201:

> It's not slower, it's faster.

Why bother bumping an ancient thread just to throw around baseless facts?

If you want to prove SQL is faster then draw up a program to do the speed test and share it around so we can see.

I think you're severely overestimating the ability of SQL, however. You're certainly plugging it for all the wrong reasons.

[Godlord]

@Robin:

> Why bother bumping an ancient thread just to throw around baseless facts?
>
> If you want to prove SQL is faster then draw up a program to do the speed test and share it around so we can see.
>
> I think you're severely overestimating the ability of SQL, however. You're certainly plugging it for all the wrong reasons.

If you are using memory-mapped files, and algorithms like binary search, SQL databases will be heavily out-performed. Most of the time you win, is what SQL databases lose whilst doing transactions, using the network and parsing queries.

The only reason to use a SQL server is when you have a single, but large dataset, that has to be shared. Even then, it's sometimes better to just implement your own solution, since databases are way too generic.

Yours faithfully
  Stephan.

[Captain_Starblazer]

Well, MySQL is easily accessed in VB 6 using ODBC. Visual Studio 6 (VB6 EE) (That I use) has many DB elements  you can put on a form. So it doesn't really matter if EO supports MySQL because Visual Basic 6 does..

[Godlord]

@Starblazer:

> Well, MySQL is easily accessed in VB 6 using ODBC. Visual Studio 6 (VB6 EE) (That I use) has many DB elements  you can put on a form. So it doesn't really matter if EO supports MySQL because Visual Basic 6 does..

Accessibility is still not a reason to use anything SQL though.

Yours faithfully
  Stephan.

[Robin]

@Starblazer:

> Well, MySQL is easily accessed in VB 6 using ODBC. Visual Studio 6 (VB6 EE) (That I use) has many DB elements  you can put on a form. So it doesn't really matter if EO supports MySQL because Visual Basic 6 does..

We never said otherwise. We're talking about how people are claiming SQL should be used because of speed when my flat-file binary system is superior.

SQL has its place. I use it for centralising accounts between many different products. Claiming it's the end-all solution to all storage situations, however, is plain ignorant.