[HoussemGaming]

Hi, who use that include ?

https://sampforum.blast.hk/showthread.php?tid=590310

[coool]

I don't use any mysql include. But, I think using them is a good idea.
And about the includes they must be updated to work with the latest plugin version.

[Astralis]

BlueG/maddinator only

[DRIFT_HUNTER]

Well recently i started a little bit complicated modular GM, and i had few ideas so i checked out that Easy SQL includes (there are 2-3 of them and at least one is only for SQLite).
But i must say i just dont see a reason for using them in the first place.


Benefit is that you get simple functions to interact with few columns. Set admin level, player money, etc...That's nice. But downside is that we need to learn that functions.

Then another downside is that there is no more complicated interactions with database like joining tables.

And select queries are not threaded, so that is a HUGE downside if you want to write lag free server. I wont argue, time that takes to send select query and return the results is blazing fast, but its still a time that server has to wait for results. Any lag spike between mysql and samp server will result in a lag on samp server.

[Vince]

As far as I'm concerned it's shit. It "dumbs down" the interaction with the MySQL server a lot. Which may or may not be a good thing depening how you look at it. But it has such a high overhead. Lots of string concatenating (slow), non-threaded queries (slow), excessive queries (inefficient), etc. One of these scripts legit uses num_rows to get a simple count. That may seem logical, but it is very inefficient and it proves that the creator himself knows very little about it; the aggregate COUNT() function is much more efficient in that instance.

[Hansrutger]

http://forum.sa-mp.com/showthread.ph...ed#post3586331

I'm not sure how it would speed things up honestly, as what this guy says should be the most logical. And as others mentioned, learning when you already have learned something is kind of redundant but also it limits you, I couldn't find a mysql_tquery (or mysql_pquery for that matter) replacement in that include, but maybe it was included and I simply just missed it!

Not saying it's a bad include but learning how to create "proper" queries is also an important step toward in the process of learning how to script/program.

Quote:

And select queries are not threaded, so that is a HUGE downside if you want to write lag free server. I wont argue, time that takes to send select query and return the results is blazing fast, but its still a time that server has to wait for results. Any lag spike between mysql and samp server will result in a lag on samp server.

I thought that was client-sided and not server-sided? I'm not sure, hence asking (the lag, aka the non-threaded query wait time).

[Abagail]

Quote:

Originally Posted by Hansrutger http://forum.sa-mp.com/showthread.ph...ed#post3586331 I thought that was client-sided and not server-sided? I'm not sure, hence asking (the lag, aka the non-threaded query wait time).

I might be misunderstanding you but all functions in the MySQL plugin are fully server sided and handled on the servers end. When you use mysql_query, it uses the same thread that the server itself uses. This means that the time it takes for the server and plugin to process the query is the same amount of time the server does nothing but wait for the result to come back (nothing else goes through).

[Mauzen]

Yep, its a query builder actually. Not just one query per field write.
I dont really like them though. Stuff you can achieve with that are just basic select/insert/update queries, takes like 20 minutes to understand them if youve never seen a SQL before. The include probably takes the same time to get into the usage, but other than SQL this isnt universal syntax, and youll have to learn it again and again for every new query builder youre using.

Also, once youve got the basics of SQL, theres barely any difference between a query and the builder in terms of readbility. The pure query usually is even easier to read for simple stuff.

So, dont use query builders to avoid learning SQL. That wont pay out.

[Hansrutger]

I had things go into the database to fetch quite big data and then making it appear in a dialog box once, can't fully remember what it was for. So it took around 300 ms, it was noticeable as you would be able to move your character inbetween the dialogs showing up.

If I would have used normal mysql_query, would this have affected the whole server or would only the player in question freeze for those 300 ms? What you're saying is that it would freeze the entire server, no? I haven't personally tested it so hence why I'm asking. :P

[Vince]

Quote:

Originally Posted by Hansrutger What you're saying is that it would freeze the entire server, no? I haven't personally tested it so hence why I'm asking. :P

Yes, the non-threaded mysql_query executes in the server thread. It is a blocking event which basically means the entire server is "on hold" while the query is executing. That means no callbacks and - most importantly - no sync. Result: lag.

[GoldenLion]

I find it a lot easier using the default MySQL functions than using this include.

[DavidGravelli]

MySQL is the best version mate
I don't think if they are using EasyMySQL

[ValueA]

Damn, Mysql isn't good that much,