Question

Ok I recently asked a question and users answered is that I should normalize my database but I don’t think I should really do it..

The logic goes like this

Am storing scripts in the database which are executed dynamically according to the user..

So for example there’s a script table

script_id | script_name
+----------------------+
12345       demo1
54462       demo2
90874       demo3
43058       demo4

And now the user table

allowed_script_ids
+-----------------+
21345|90874

So this is simple here, but what happens is if I delete say script_id 90874, but it doesn’t remove the record from the user table so they suggested me for normalizing the database, but what if user has access to 1000 scripts? do I need 1000 records for that? Or I should continue with the way am going? Even If I insert each record entry for each access, I need to delete those everytime I revoke the access for that user.

Answer 1

1000 rows are not a lot (in the same light, nor is 10,000,000), normalising your database (ie. associating users to scripts) is perfect fit for this. If you’re concatenating a string, unless you’re using TEXT (which is baaaaad for this anyway!), you’re probably going to hit some form of field length limit before you can add too many script IDs anyway.

So yes, I would also suggest that your normalise to this extent:

Script

script_id
name

User

user_id
...

User_Script

user_script_id
user_id
script_id

.. each relationship will then go into User_Script.

This is much cleaner than concatenating a string, and upon deletion, seeking/replacing from a string. It will be faster, cleaner, and help you actually see your database in a much more streamlined way.

Currently, how would you get all of the script names out of the database? With the above somewhat-normalised design, you can run this query similar to this:

SELECT `user`.`first_name`, `script.name` FROM `User_Script`
INNER JOIN `Script` USING (`script_id`)
INNER JOIN `User` USING (`user_id`)