About Store Forum Documentation Contact
Donations:
309$/mo



Post Reply 
SQL question
Author Message
1991mirec Offline
Member

Post: #1
SQL question
Hi is there any viewer or anything i can do so when i check out the table it would show me updated numbers.. so for example if i have players position send to sql every 2 seconds it would show me the number change right in the table without refreshing the table. sql lite works but i have to somehow refresh it every time.. and i don t want that..

Or if there isn t any viewer can I make my own and somebody could point me out where to start?? smile
05-16-2014 09:07 AM
Find all posts by this user Quote this message in a reply
Rubeus Offline
Member

Post: #2
RE: SQL question
I would personally avoid reading/writing to SQL unless I am saving/loading. Accessing every 2 seconds for a lot of players would be VERY expensive.
05-16-2014 01:27 PM
Find all posts by this user Quote this message in a reply
aceio76 Offline
Silver Supporter

Post: #3
RE: SQL question
(05-16-2014 01:27 PM)Rubeus Wrote:  I would personally avoid reading/writing to SQL unless I am saving/loading. Accessing every 2 seconds for a lot of players would be VERY expensive.

I have to say this will vary, but I mostly do not agree with this statement because enterprise-level SQL servers are built to handle dozens of requests per second. Again, I will caveat that it will depend on db design and application design, but in general, SQL (MS SQL, MySQL, other enterprise-grade SQL) can handle even over a thousand transactions per second. The question then becomes do you want to offload data to the db that often or not, do you want the latency that the DB introduces when getting/setting data vs having it in cached locally, and the list goes on.
05-16-2014 05:42 PM
Visit this user's website Find all posts by this user Quote this message in a reply
Rubeus Offline
Member

Post: #4
RE: SQL question
(05-16-2014 05:42 PM)aceio76 Wrote:  
(05-16-2014 01:27 PM)Rubeus Wrote:  I would personally avoid reading/writing to SQL unless I am saving/loading. Accessing every 2 seconds for a lot of players would be VERY expensive.

I have to say this will vary, but I mostly do not agree with this statement because enterprise-level SQL servers are built to handle dozens of requests per second. Again, I will caveat that it will depend on db design and application design, but in general, SQL (MS SQL, MySQL, other enterprise-grade SQL) can handle even over a thousand transactions per second. The question then becomes do you want to offload data to the db that often or not, do you want the latency that the DB introduces when getting/setting data vs having it in cached locally, and the list goes on.

I would find flushing to disk at x interval and on exit as well as only reading when loading would be a more economical solution. This way, the server would be reading the player positions from memory(x ns lookup time) vs from disk(4-15ms). Keep in mind that requesting a read will tie up the response by that amount of time(not to mention the time it takes to actually search the DB). If someone is connected with 40ms latency, adding 7ms(average seek time) is nearly a 20% increase.
Granted, if One has an enterprise array like and EMC or 3par or Oracle as Aceio is talking about, they can handle a crapton of requests before they start to get bogged down, but there is still going to be the seek time of the hard drives(4-15ms). Not to mention, this is expensive monitarily as well.

TL;DR Reading and writing realtime as a method of getting information from the server for gameplay is usually a bad idea. Reading once to get the required information is pretty standard, but it's often better to try to keep the information that is actively being accessed in memory, with the occassional write to make sure information isn't lost during an unexpected event.
05-16-2014 07:05 PM
Find all posts by this user Quote this message in a reply
1991mirec Offline
Member

Post: #5
RE: SQL question
thnak you guys for your responses.
so in other words if i have server window up and running i should just make a place to display it right in the window rather then sending it to the sql.db..

If i understood you correctly.

and you said that unless it saving loading.. so what are you sayng it is better do saving loading with sql rather then using file system in esenthel?? cause you can do saving and loading with server using files.. which way would you say is better??
(This post was last modified: 05-16-2014 08:17 PM by 1991mirec.)
05-16-2014 08:15 PM
Find all posts by this user Quote this message in a reply
Rofar Offline
Member

Post: #6
RE: SQL question
It depends on who you ask. For instance, I would choose file IO almost 100% of the time over relational database. Obviously, there are cases where it makes much more sense to save data in a database but for serializing classes and basic data structures for a game, I'd rather not complicate it with database connections and SQL statements.
05-16-2014 10:14 PM
Find all posts by this user Quote this message in a reply
aceio76 Offline
Silver Supporter

Post: #7
RE: SQL question
Yes, the consulting answer is almost always, "it depends" smile

If you are accustomed to working with enterprise database servers, there are inherent positive things to be had incorporating the use of sql. In Rubeus' example, he talks about slow disk activity when the sql engine is reading from the db the first time, but that doesn't account for caching and other "intelligence" the sql engine has, so in effect, data reading can be much faster than what Rofar is mentioning with regards to accessing a flat file, where every read could potentially be (and likely is) a new file operation each time. Please note that I am NOT comparing this with memory-based caching, we can all agree that's the fastest, but that's not what were talking about here.

Here's some quick things to think about:
- if your project doesn't require multiple users accessing the same data over and over at the same exact time (not concerned about file-locks, data consistency, etc), you probably don't need a db (hence a sql engine is not needed)
- if you don't have a need for multiple "servers" or "agents" accessing the same data from different computers/networks at the same exact time, then you probably don't need a sql-engine based db
- if you don't have a lot of data to store and don't need a purpose-built system to offload or handle data access and management (which is what SQL and the like is made for), then you don't need a sql-engine based db
- if you don't have a need to mine the data (data-mining) that your game records (to learn patterns, find data of a specific type, change data based on filter/pattern, etc), then you probably don't need a sql-engine-based db

There are others, but those are probably some of the big items.

Now, nothing is stopping you from still using a sql db to hold your data, but what does it buy you? That's what you need to answer. Sometimes, all it takes is something as simple as having a ui to look at the data, because sql (sql-lite for instance), has a nice ui that allows you to look at the saved data and change things thru the ui, then by all means use sql-lite. But if your needs align more with at least the items above, then maybe you need an enterprise level db using sql.

Using an enterprise level sql to manage data is highly scalable (if you need it, that is), nothing can match that, since it's purpose built especially for that. But, if you don't have true experience in it, like I did 20 yrs ago, you will think that it's not operationally faster in many data management cases. It's also not necessarily more complex as far as coding is concerned, but it does add complexity to your infrastructure (your app now requires a sql engine running somewhere, and all the complexities of that sort of set up) but if that's what you need, that's what you have to do, and a sql engine is an integral part of that, no one can argue that otherwise.

In short, how robust do you need your data management to be??? Only you can answer that question.
(This post was last modified: 05-16-2014 11:16 PM by aceio76.)
05-16-2014 11:10 PM
Visit this user's website Find all posts by this user Quote this message in a reply
Rubeus Offline
Member

Post: #8
RE: SQL question
Keep in mind that I'm preaching against writing disk often in general: everything said I agree with. But writing to a DB or a file even as spaced out as every 30 seconds is pretty extreme, given the constraints. I prefer an event based I/O system where things are read or written only if certain conditions are fulfilled to keep the disk operations to a minimum. Aceio, you are correct, but when I was referring to the seek time, that's the basic time it takes the head to move to the correct position on the platter regardless of what program is calling for the data. Processing where the data is on the platter is extremely quick in SQL, and adds only a negligable amount of time, especially with caching and such.
For outputting information specifically for reading debug information, I would personally use the LogConsole(); in Init() and Log(S + "ObjType InfoType: " + infoToShow + "\n" ); in an update(maybe with a time check to prevent excessive spam). (I use that format so when I want to disable or change it, I know to look for ObjType in ObjType.cpp and don't have to hunt for it.)
05-17-2014 12:29 AM
Find all posts by this user Quote this message in a reply
1991mirec Offline
Member

Post: #9
RE: SQL question
thank you guys for clearing out some things for me.
05-17-2014 11:42 AM
Find all posts by this user Quote this message in a reply
Rofar Offline
Member

Post: #10
RE: SQL question
As usual, Aceio provides a detailed and accurate answer smile
05-17-2014 10:13 PM
Find all posts by this user Quote this message in a reply
Post Reply