Quick SQLite Field Creation - Printable Version

+- SA-MP Forums Archive (https://sampforum.blast.hk)
+-- Forum: Other (https://sampforum.blast.hk/forumdisplay.php?fid=7)
+--- Forum: Everything and Nothing (https://sampforum.blast.hk/forumdisplay.php?fid=23)
+--- Thread: Quick SQLite Field Creation (/showthread.php?tid=591145)

---

Quick SQLite Field Creation - Gazzy - 08.10.2015

Hey guys. I was wondering if there was any easy way to make fields in SQLite? Like is there a way to execute SQL to make a table or add those fields? I have like 200-300 player variables that I need to add and I really really don't want to add them by hand. Thanks in advance!

---

Re: Quick SQLite Field Creation - Spmn - 08.10.2015

ALTER TABLE `table_name` ADD `field_name` field_type;

---

Re: Quick SQLite Field Creation - Vince - 08.10.2015

"200-300 player variables" should never be in one single table. The player table should only contain the most vital information (username, password, etc) and all the rest should be structured away so that you can keep an overview. I would say a single table shouldn't have more than 30 columns. I want to bet that you also have columns like carmod1 all the way to carmod13, and in that case read my tutorials.

---

Re: Quick SQLite Field Creation - Mauzen - 08.10.2015

Well, for best results you should do it manually. Only you know the range and type of all those variables. Probably many of them e.g. are boolean bits. Making everything a 32 bit int would then cause a massive overhead, and thats not only bad style, but it makes things inefficient (and strings wouldnt work at all). Using that many fields in a single table also makes things more complicated than neccessary. Be sure not to use "SELECT *", unless you want to torture the shit out of pawns sql interface. Certain queries will exceed the maximum query length of pawn and mysql, you wont be able to save everything with a single query, but youll have to use alternative saving techniques (I wouldnt recommend single-query-saves anyways, even for small tables, but thats a different story) . Handling such large tables is a pain.
Better use mutliple tables for different topics, and JOIN them where neccesary (though "SELECT *" still shouldnt be used then to keep things clean).


If you really want to parse this automatically, Id suggest a small script of some sort. Maybe PHP, or even pawn. Go through your variables line-by-line (assuming you only got one per line, else youll have to split lines by themselves again). Check the variables tag and eventually the array size, and add the corresponding field type to a CREATE TABLE query. Again, watch out not to hit the maximum query length, better stop every 50-60 fields and continue with ALTER TABLE.

Nevertheless, theres barely any case where you really need that many player variables when scripting properly. Your script could probably use some optimisation. Bad enough that its "200-300", not knowing the exact number is a clear sign of a bad style.

---