Quote:
Originally Posted by Oo Alias oO
There's quite a few complex relationships involved and having to work these out with SQL can cause issues... For example the N+1 issue could easily come into play. This obviously is easily avoided using an API.
|
You know, you can do a JOIN by yourself in your plugin or whatever else MySQL offers. Those problems are not in any way related to SourcePawn or PHP, but more to the developer that write the queries. (PEBKAC :p)
I personally don't think there's any real complexity involved there.
Quote:
|
Security wise, you don't pass any database credentials into the plugin at all, just a easily changeable API key and URL. To me, that's more secure.
|
Without access to your filesystem, there is no way anyone can read your databases.cfg file. With your system, the same applies (access config, get access). Plus passing a password (yes, a password) as a HTTP header value is in general not a good idea.
How could that be more secure when you add things that can grant access? It's like having two keys that open the same door, it can't be better (in terms of security) than having only one.
Quote:
|
As for slowing down querying, I don't see why? If anything, the queries will be more optimised, only returning the exact data needed.
|
Plugin -> Database -> Plugin
Plugin -> HTTP -> Database -> HTTP -> Plugin
You're adding parts to the process, it's kinda obvious that it can't be faster.
I assume you'll be using an ORM to manage your queries, and they are not made to be fast but simple to use. So, for the small complexity of the queries that will be issued by the plugin, you're adding an extra layer that is slow and useless from my point of view.
If you're not gonna use an ORM, you're writing the queries yourself. In this case, you're adding an extra layer for absolutely nothing you can't do in the plugin.