General > Developers Corner
UCL to SQL Discussion
Megiddo:
Roastchicken, look into BCNF -- it will help you come up with a workable schema.
roastchicken:
--- Quote from: Megiddo on February 09, 2016, 04:26:20 AM ---Roastchicken, look into BCNF -- it will help you come up with a workable schema.
--- End quote ---
I think I looked into something like this previously, where you would have (for example) one table for users and then a separate table for users' allowed commands. I'm not sure why I didn't think of this.
Another thing I'm thinking about in terms of the database schema is removing the steamid column. Originally I had it there so people could add someone by SteamID without knowing their SteamID64, but I'm not sure if it's a good idea to have that redundant column just so that people can manually edit the database file to add players. If they really wanted to they could just use an online SteamID finder and get their SteamID64 that way. Thoughts?
Megiddo:
You can convert steamid formats in Lua. It's a somewhat arbitrary decision. No point in duplicating data.
roastchicken:
--- Quote from: Megiddo on February 09, 2016, 01:55:01 PM ---You can convert steamid formats in Lua. It's a somewhat arbitrary decision. No point in duplicating data.
--- End quote ---
Yeah, I know of the functions to convert to/from the two SteamID formats. I was just thinking of the edge case where someone wants to manually edit their sv.db file and add a user by SteamID, but that's really specific and they can just convert it to SteamID64 if they absolutely must add the user by editing the database (not a good idea, if anyone is wondering).
I'm currently in the process of normalizing the schema, but I've come a cross a bit of a snag. The only way I can think of storing access tags is using NULL values, which technically goes against normalization. If anyone has any ideas on how to store access tags without the use of NULL values, please let me know. Then again this is a really nitpicky side of database normalization and as far as I can tell there isn't much reason to follow it.
Megiddo:
As with all "best software/database practices", you have to draw the line somewhere. Sometimes utility trumps sexy.
I personally have no problem with appropriate use of nulls. I believe this is an appropriate use.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version