Why are the table names different? 1. "assign_role_to_user" (one_to_one) 2. "assign_modules_to_roles" (many_to_many) In the "user_privileges" table, there are column names that are reserved in SQL. I guess you shouldn't use those?
Thank you for the question. I appreciate it. Yes, in the user privileges table using MySQL for the web development and not this microsoft access used to demonstrate the assignment given, insert, update, delete, and select were not used as attribute names, and I understood why. In a real-life scenario, if you try to use them as attributes on the user_privileges object within an Object-Relational Mapper (ORM) or structured SQL, you will encounter issues because they are reserved words. The actual attribute names are can_insert, can_update, can_delete, and can_select or you can give it any name you want. In a real-world scenario using a MySQL database, the modules are automatically generated based on the module registration within the application. But for the purpose of this class we just stored them in the module table. As for your question about why the tables are different, let me explain. The assign_role_to_user table keeps track of users and their associated roles, while the assign_modules_to_roles table keeps track of the application's modules and their associated roles. Now, let me tell you why this distinction is important and to correct the one-to-one It's very possible for two users to be assigned the same role, but one person cannot have multiple roles. These are validations that need to be considered when developing the application. The reason for this is that even if two or more people have the same roles, it does not necessarily mean they will have the same privileges. I hope I answered your question. Thanks for the observation.
Why are the table names different?
1. "assign_role_to_user" (one_to_one)
2. "assign_modules_to_roles" (many_to_many)
In the "user_privileges" table, there are column names that are reserved in SQL. I guess you shouldn't use those?
Thank you for the question. I appreciate it. Yes, in the user privileges table using MySQL for the web development and not this microsoft access used to demonstrate the assignment given, insert, update, delete, and select were not used as attribute names, and I understood why. In a real-life scenario, if you try to use them as attributes on the user_privileges object within an Object-Relational Mapper (ORM) or structured SQL, you will encounter issues because they are reserved words. The actual attribute names are can_insert, can_update, can_delete, and can_select or you can give it any name you want.
In a real-world scenario using a MySQL database, the modules are automatically generated based on the module registration within the application. But for the purpose of this class we just stored them in the module table.
As for your question about why the tables are different, let me explain. The assign_role_to_user table keeps track of users and their associated roles, while the assign_modules_to_roles table keeps track of the application's modules and their associated roles. Now, let me tell you why this distinction is important and to correct the one-to-one
It's very possible for two users to be assigned the same role, but one person cannot have multiple roles. These are validations that need to be considered when developing the application. The reason for this is that even if two or more people have the same roles, it does not necessarily mean they will have the same privileges. I hope I answered your question. Thanks for the observation.