Quote:
Originally Posted by Hezzy002
I think most of that out there is misinformation in this case. Most of it points toward general-purpose use, and yeah it looks like it's a poor choice for that. But in this case, I'm definitely cutting out a few comparisons on SQLite. I'm not sure if SQLite builds a hash table every time you add a value, and then links all the similar values to a single hash value, but either way, this method would cut down on at least one step since I need all the values in the table. Otherwise, it'd have to link tons of values to a single hash, or if SQLite isn't as efficient as it should be, tons of string comparisons.
|
You really aren't making it easier for SQL though. It's still going to have to do that exact same check if the table exists.
Your table should just be:
account
flag
value
add an index to account and you're good to go.
Your attempt at making it more efficient by giving each account their own table is actually much more in-efficient.
If you have 10 people online and you call shareVars on one person, you're calling around 12+ queries (and triggers too) in one call.
If you made your table properly, you could use one query to get everyone's flag and variables. I.e:
SELECT account, name, value
FROM flags
WHERE account IN ('account1', 'account2')
Package the result up and send it to your client.