2
Contributors
9
Replies
10
Views
10 Years
Discussion Span
Last Post by debasisdas
0

thats OK ,but u have mentiond only PK ,what about foreign keys .
you have not mentioned how are you maintaining ralations.

0

thats OK ,but u have mentiond only PK ,what about foreign keys .
you have not mentioned how are you maintaining ralations.

in MODULES, FK is review_id

in MODULES_ROLES_USERS, FK are module_id, user_id and role_id

in MODULES_TASKS_USERS, FK are task_id, module_id and user_id

in ROLES_TASKS, FK are role_id, task_id

makes sense?

0

it seems to be a good design following norms, but all depends on what is the logic you are going to implement on that. How youare going to use that is more important , on which i have no idea. It might happen you have to make some minor changes later on.

0

it seems to be a good design following norms, but all depends on what is the logic you are going to implement on that. How youare going to use that is more important , on which i have no idea. It might happen you have to make some minor changes later on.

I have uploaded a document with the description of the system. Someone has also remarked to me that I should split the modules_roles_users table into three: modules_roles, modules_users and roles_users but im not sure if this is better, what do you think?

0

As per rules of normalization ,that sounds good but in most of the cases we have to de-normalize the database to avaoid un-necessary complexcity. You can go with the structure and always there is room for improvement. Different people have different openion on the same scenario, and this is my personal view only.

0

As per rules of normalization ,that sounds good but in most of the cases we have to de-normalize the database to avaoid un-necessary complexcity. You can go with the structure and always there is room for improvement. Different people have different openion on the same scenario, and this is my personal view only.

So you think i should be able to work with it even without splitting those tables?

0

also i am unsure about using a separate id field for the primary key in the join tables rather than using the two foreign keys together as a primary key. what is ur opinion on this? thanks

0

no need to split the tables further, it might look efective to you initially but later on will create more problems than it will solve and will be difficult to manage as the tables grows.

0

also i am unsure about using a separate id field for the primary key in the join tables rather than using the two foreign keys together as a primary key. what is ur opinion on this? thanks

Even though u can use composit keys ,it is always recommended to use Primay key and again composit key based on foreignkey is not that recommended for any purpose. That should be used as the last option.

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.