SQL access from .NET server library

Hi Chris,

Is it possible to access the SQL database from the server program, without limiting access to a single user ( eg the Data API ).

In particular, I'm interested in designing games where players can design their own levels, maps and content. The data API would allow this on a pr user basis, but there's no fun in being that only person who can play a map you just designed!

It'd be great if the .NET libraries could access the SQL server, as being able to store data strings that can be accessed for any player via the server would make user created content easy to implement.

Its a good ide and we have been looking into it. It is however highly complex in a system thats build to scale. But we are looking at it.

cool... i have actually been thinking about this!
not that i have anything ready, for data access but it would defiantly be cool to be able to store, some global server variables, instead of being limited to a single user!

ill be looking forward to this :D

Is the complexity keeping the sql databases in sync?

Could it be an area worth asking developer's to help with?

For a (or a group of) developer(s), it would be less work to build the ability into Nonoba then it would be to design custom server software, and once part of the Nonoba framework it would be a benefit to everybody.

what do you mean by, keeping the database in sync?
i have never worked with SQL databases in C#.net, but i have worked with it in vb.net, and the differences is pretty small...
as i see it, its just opening a connection to the database, retrieve the data, and then just send it to the client, as you normally would.
but i may be overlooking something, that would make that a very complex thing to do? :/

anyway, i think another problem would be actually getting access to the database... for some people at least.
for example, my MSSQL database, only allows connection from the same server.

I was asking if the complexity was from having multiple SQL databases (eg in a situation where a game uses more resources then a single server can supply). I see that being a challenge.

The Data API, where strings of information can be stored on a pr user basis, would have many of the elements needed. It's hopefully just a matter of creating a 'universal user' or similar.

The hardest thing to do, is making the complex simple.

We feel that the service we're providing with the multiplayer API is taking away all the hard parts of building multiplayer games, including scaling.

There are two main problems with giving access to sql/databases from within multiplayer games:

one) The amount of management required because each game would need it's own database, and some sort of user interface to setup tables, run queries etc.

two) scaling: ensuring that a very successful game can to any amount of users without dying from deadlocking or saturation of a single server. This problem get's even worse if we try to share database servers with multiple users.

With our current apis's we don't have that problem, because everything is built with sharding, so we can always pop-in extra servers and handle more load, and we've designed the api methods so they scale linarly (no twisted joins that exponentially grow to use all resources very fast)

What we're talking about, is making API's that work for generalized, common usecases, like for instance allowing users to generate levels or content and share that with others.

Best,
Oliver

That makes a lot of sense.

For storing user generated content etc an equivalent system to the Data API would work. Storing and retrieving strings (or maybe byte arrays from a blob sql object) would be more then enough to play with.

I'd assume being given direct SQL access would best avoided - I know I'd end up breaking my own games sooner or later if I dealing with raw SQL. (The join commands and I don't get along!)


So, let's replace SQL access with string keys like the Data API :)