Best way to save an array into SQL, and a question about cellmin

Best way to save an array into SQL, and a question about cellmin - Printable Version

+- SA-MP Forums Archive (https://sampforum.blast.hk)
+-- Forum: SA-MP Scripting and Plugins (https://sampforum.blast.hk/forumdisplay.php?fid=8)
+--- Forum: Scripting Help (https://sampforum.blast.hk/forumdisplay.php?fid=12)
+--- Thread: Best way to save an array into SQL, and a question about cellmin (/showthread.php?tid=558021)

Best way to save an array into SQL, and a question about cellmin - xVIP3Rx - 15.01.2015

What's the best way to save an array into SQL, like player weapons and ammo.

Also I've asked a question in the 'Little coding questions - For general minor queries 5' but didn't get any help, hope somebody replies here.

Quote:

Originally Posted by xVIP3Rx

I've ran into this fix by Slice but I have trouble understanding what is "cellmin" and why is he packing the packed string (cellmin_value) when pack is true.

pawn Код:

// valstr fix by Slice
stock FIX_valstr(dest[], value, bool:pack = false)
{
    // format can't handle cellmin properly
    static const cellmin_value[] = !"-2147483648";
 
    if (value == cellmin)
        pack && strpack(dest, cellmin_value, 12) || strunpack(dest, cellmin_value, 12);
    else
        format(dest, 12, "%d", value), pack && strpack(dest, dest, 12);
}
#define valstr FIX_valstr

Re: Best way to save an array into SQL, and a question about cellmin - Abagail - 15.01.2015

I'd recommend simply placing them an integer value with columns like

pawn Код:

Player_Weapon_Slot_%d

so you can use a loop to load the data by the slotID of the gun, etc.

Re: Best way to save an array into SQL, and a question about cellmin - xVIP3Rx - 15.01.2015

That would make ALOT of columns, for example if I have an "Array[30]", it would make a 30 columns, and for every array that would be more than 100 columns just for few arrays.

Re: Best way to save an array into SQL, and a question about cellmin - Abagail - 15.01.2015

Well: I Mean SQL isn't good for arrays, and all that: maybe use an .ini for things like that? If it's for player weapons, maybe something like:

Player_Weapons_%s.ini

%s being the players name. You probably get where I am going; .ini files are better for array, and non-"indexed" or "columned" data storage.

Re: Best way to save an array into SQL, and a question about cellmin - Vince - 15.01.2015

Quote:

Originally Posted by Abagail

I'd recommend simply placing them an integer value with columns like

pawn Код:

Player_Weapon_Slot_%d

so you can use a loop to load the data by the slotID of the gun, etc.

This is the absolute WORST thing you could do.

You might want to read: https://sampforum.blast.hk/showthread.php?tid=505081

Re: Best way to save an array into SQL, and a question about cellmin - xVIP3Rx - 15.01.2015

Quote:

Originally Posted by Vince

You might want to read: https://sampforum.blast.hk/showthread.php?tid=505081

I've read the other one with connecting two databases together and actually did it, but with more arrays it became huge and hard to manage;

Quote:

Originally Posted by Vince

Does not conform to the standards of normalization. Multiple values per column is fundamentally wrong.

Alright, Thanks.

Re: Best way to save an array into SQL, and a question about cellmin - Vince - 15.01.2015

Does not conform to the standards of normalization. Multiple values per column is fundamentally wrong.

Re: Best way to save an array into SQL, and a question about cellmin - Abagail - 15.01.2015

Quote:

Originally Posted by Vince

This is the absolute WORST thing you could do.

You might want to read: https://sampforum.blast.hk/showthread.php?tid=505081

I dont really store arrays, that much, - but can you explain why it is such a bad way of storing array data? I'm assuming it'd slow down the MySQL server / queries, or something alike?

Re: Best way to save an array into SQL, and a question about cellmin - Vince - 15.01.2015

Because in real world applications you don't use "SELECT *". This is something considered to be only used by database administrators and developers while testing or developing but it should not ever be included in any finished products (we use this in SA-MP because core functionality is extremely limited and there's hardly any string functions). Suppose I need to save an array with a thousand values. Am I going to make a thousand columns? Of course not.