MySQL Support

[Messiah2]

MySQL Support

I think it would be very good to make mysql support in runuo core for storing accounts and statistics... Because this db server is very popular.

 

[Ray]

This doesn't need core support, it's perfectly possible to do with own scripts.

For most purposes MyRunUO, which is included into the retail scripts will serve you fine. It's capable of storing your data.

If not, i've got an asynchronous I/O mysql handler that could help about that. But it's still beta, no odbc, native MySQL (additional driver-dlls), no comfort, etc. PM me if you want to take a look, it's not ready for a release this time..

 

[Seanchen.net]

I think it would be very good to make mysql support in runuo core for storing accounts and statistics... Because this db server is very popular.

There are more popular database backends then MySQL, and most likely those other choices would be better for what you want.

But like somebody already said, this doesn't require a core modification to make it work, so your welcome to start on it.

 

[Nelzie]

I think it would be interesting to see a MySQL, or other freely available DB Engine, to handle everything from accounts to items and even objects in game.

It could provide for the creation of a simple interface to allow world builder's to easily add content to their worlds in the form of new equipment, new placeables and new creature modifications.

 

[milt]

But then again wouldn't it be less secure? I beleive (but not positive) that there are security riskes in MySQL that could be taken advantage of. I think that using the save files stored on the computer is better because of security issues, but that is just my opinion.

 

[brodock]

If you want MySQL to handle your accounts... take a look at MyRunUO... it exports all your accounts info to a mysql account (to be used in system like "MyUO")...

I'm assuming you want runuo to save in a mysql server so you can develop website integration in someway, so here is your solution...

But if you really think that mysql database is better then XML (only for running a shard) i think you should consider that having database in MySQL means you have to run a MySQL server too in the same machine... (performance problems... probaby)

 

[Courageous]

Xpath really isn't any harder than SQL, IMO. So for the stuff stored in XML already, I view this as a wash (unless of course one wants to do something like web accounting... possibly easier with an ODBC driver). For storing the shard itself, there might be some benefit, depending, but I'm not really seeing it. I suppose if one feels a need to do surgery on the saves...

C//

 

[xir]

I'd love to see someone change RunUO to be implemented with an oodbms as an alternative. It would add a new dimension to the way application tools are developed and also make the realisation of non-blocking world-saves, server clustering/distribution a possibility. Something novel and not done before is what the UO community needs. Even if it is not of much practical use, it is always interesting to try out new technologies.

 

[Courageous]

You mean like Objectivity or Object Store? Yes, I remember some conversations I had some time back with parties unmentionable at OSI about this. IIRC, they used Oracle... had they gone for a commercial grade oodbms, things would have been oh so much faster. Don't you think such a solution might be a bit too complex for the more casual hobbiest community, though?

Which oodbms did you have in mind?

C//

 

[Ray]

hm... saving the world into the database and read them back again should possible with async i/o db.
It's just the question of effort and how complex it should be.
While saving into the db with current methods (all at once) is quite easy,
a partial save (serialize one object at modification) would be more complex
and an atomic save ( update only modified property ) would be way too much

Most modern database-engines should be able to bear that.

 

[Courageous]

The way a commercial grade oodbms works is that the updates are handled automatically, when the objects are mutated. The underlying oodbms implements a thin layer over the operating system and hardware paging mechanisms, making your application sort of like Oracle itself, as opposed to a program that uses Oracle. For systems of objects that are highly interwoven (complex graphs), oodbm's are indisputably the performance leaders, simply killing the table based databases. OTOH, they are not nearly as convenient as the table oriented databases, they can be tricky to set up, and really require specialists to keep them up.

C//

 

[xir]

I have very little experience with databases in general and just a theoretical knowledge of object-oriented databases so I wouldn't be able to recommend one in particular. You could just create an interface/layer and perhaps plugin different implementations if one wanted to support different dbs. Although you could store the world in a relational database, an object-oriented database seems like an obvious and elegant solution for persistant objects in an object-oriented design such as RunUO. I'm not aware of the complexities of intergrating such a solution, but I assume it shouldn't be any more trickier if not easier to implement than a relational db implementation as one is working on the same level of abstraction. Anyway just some thoughts.

 

[Courageous]

Well, understand that most OO dbms's are implemented right on top of the class objects. So imagine myobject.Name = "Courageous"; being automatically persistent. This is done in a highly efficient way, by marking the memory associated with the object as "dirty," and then flushing entire pages at a time to disk in native binary form (no serialization) on an organized basis. To pull stuff off of disk and into memory, they do things like intercept the "." operator between object references, in hashtables, and the like. You're probably wondering how they do all this, yes?

It's through code generation, and by representing the objects in an intermediate format, something like IDL.

C//

 

[Nelzie]

If you want MySQL to handle your accounts... take a look at MyRunUO... it exports all your accounts info to a mysql account (to be used in system like "MyUO")...

I'm assuming you want runuo to save in a mysql server so you can develop website integration in someway, so here is your solution...

But if you really think that mysql database is better then XML (only for running a shard) i think you should consider that having database in MySQL means you have to run a MySQL server too in the same machine... (performance problems... probaby)

Why would both RunUO and the theoretical MySQL back-end need to run on the same machine?

The way I see it, someone could run a MySQL server with whatever flavor of OS floats their boat, run a Web server in conjunction with that, to enable the ability to build some dynamic pages with data from the DB, without negatively impacting the performance of RunUO on a server dedicated to RunUO.

If it would have DB support, it would have to support a DB that is available locally or externally.

 

[Courageous]

I think you're perfectly right about this, Nelzie. I would presume that someone wanting accounts on MySQL is probably doing it for web accounting, in which case I'd likewise assume they're getting MySQL through their web host. It's a common option (for example, I have one for my web host through speakeasy). I'd just use that, myself.

C//