[Guest4390857394857]

Quote:

Originally Posted by PowerPC603 Really? To me, it seems he's using this huge query everytime something happens in this server, using even more resources and create even more lag. Some player's money changes -> huge query to update everything. Another player's score changes -> same huge query to update everything. A third player changes his skin -> same huge query that updates everything. While the same result can be done by 3 different and small queries: Money changes -> update the money using a small query. Score changes -> update the score using a second small query. Skin changes -> update the skin using a third small query. Who would get the best results and least lag? The one using the same huge query for everything, or the one who uses many small queries to only update the fields that change, leaving all the rest out of his query? There is really no need to update every field when only 1 value changes. And yes, for every kill, he would need to send a query. In case the player disconnects (timeout or whatever reason), or the server crashes, you get the least dataloss when you save everything at the moment it changes. That's how big MMORPG servers save their data as well. In fact, that's how EVERY server saves the data. As soon as the data changes, use a query to store it in the database, using a query that only takes the fields that have changed. How would you save it? Once every half hour or so? Alot can happen in half an hour. He might do 15 missions, buy a house, kill 25 people, sell a car and buy a new one. If the server crashes right before it's time to save the data, your player WILL lose everything he did in that half hour and will need to redo everything he did. If it happens alot, he might just leave your server because of the frequent dataloss.

A better database structure (design) would make it perfect! Calm down m8

Quote:

Originally Posted by Vince Are you kidding me? MySQL was built to handle large amounts of data and if you use threaded queries it won't cause lag. Yet, this is once again a prime example of a non-normalized database. Everything in one table, because ... reasons. Now, this is purely hypothetical, but please stay with me. A physical person can have one account (table: users). Each account can have multiple characters (table: characters). Each character can have multiple licenses (table: licenses). Each character can have multiple drug types (table: drugs). Each character can belong to multiple factions (table: factions). Each faction can have multiple cars (table: faction_cars). And so on and so forth. Database design is something you need to think through very carefully. You may want to draw it out on a piece of paper first.

Yeah I agree