In my model I have a User table, Role table, and Organization table.
A User can have more Roles with more Organizations independently.
So far I saw in any tutorial that a link table has two foreign keys (left, right), but in my case I need a link table where there are User-ID, Role-ID, Organization-ID fields as foreign keys and primary keys as well.
some example:
user role organization
=== ==== ============
u1 admin orga1
u1 admin orga12
u1 reviewer orga3
u2 editor orga1
Thanks in advance!
I think what you actually want is something like a user table, and an OrgRole table. You then want a joint table User_OrgRole that joins them. You might want to place a constraint on the table to make sure Org and Role are unique together.
OrgRole might look like this:
OrgRoleID [KEY]
Org [FKey]
Role [FKey]
User_OrgRole might look like this:
UserID [Key]
OrgRoleID [Key]
You can certainly do the 3-way join manually, but you will not be able to create any many-to-many style navigational properties or relationships. You're instead creating what amounts to 3 one to many's.
Related
I'm creating a website and I only want certain users to be granted the privilege of creating a post.
I have a table named Accounts where each user's basic information is stored (Id, firstName, lastName, email). Should I include a createPrivilege attribute in the Accounts table?
Or should I create a separate table named Privileges where I have the columns (id, createPrivilege) and the Id is a foreign key referencing the Accounts table's Id attribute?
If "createPrivilege" is an attribute of "Account", and there is only one instance of that attribute for any given entity, the common pattern is to have that as a column in the Account.
However, that approach quickly becomes very messy - you're likely to have many privileges, and adding new columns for each will make the "account" table very messy.
The most common way to model privileges is to introduce the concept of "role". A single user typically has several roles. A role might be "anonymous user", "authenticated user", "moderator", etc.
So, my recommendation would be to have a table with "account", a table called "role", and a join table "account_role" with foreign keys to both.
Do I really need an extra identity field say called id on a bridge table? For primary tables I set an id and have it start incrementing from 0. But not sure about bridge tables.
Example:
user
user_id (identity)
name
user_communities
id (identity) - do I even need this??
user_id
community_id
communities
community_id (identity)
name
No, you don't need an additional generated primary key on a bridge table - at least not if (user_id, community_id) is the primary key.
You would only need it in case you would allow a user to participate in the same community multiple times, e.g. with different roles.
Your relationship links two entities, thus you have the ids of the two entities in it. In that case the id in your bridge table is unnecessary.
But, although rarer, you could also have higher order relationships which connect two relationships or a relationship with other entities. Say, for example, you want to qualify a relationship with a set of properties (the strength of the relationship, its participants, etc), you could have a relationship properties table that links to the relationship (thus you would need its id) to a set of name-values pairs. You could even have a bridge table between two different bridge tables to connect them and assign certain properties to the connection (which relationship has priority over the other, e.g.)
I could go into the EDMX in design view and update the cardinality (1-, 0-, etc.) of associations, but I want to know if it is alright to do that in this scenario.
I have these two tables, let's say:
User
-----
Id
UserProfile
-------------
Id
UserId
Stuff
A single user may have just one profile. Therefore, I have set a UNIQUE constraint no the UserId column in the UserProfile table. Also, UserProfile.Id is defined as a foreign key that references User.Id.
However, in the Entity Framework model, I get the following:
class User
{
ICollection<UserProfile> UserProfiles { get; set; }
}
At first, I had the UserProfile table without any primary key of its own like this:
UserProfile
--------------
UserId
Stuff
But EntityFramework made that read-only as it needed to have a primary key on every table that you want to be made writable. So, I put an Id column in the UserProfile table as well.
UPDATE
I tried setting the multiplicit/cardinality of the association between the User table and the UserProfile table in my EDMX in the designer. However, I get this error suggesting I should turn it back to what it was, i.e. a one-to-many relationship.
Running transformation: Multiplicity is not valid in Role 'UserBasicProfile'
in relationship 'FK_UserBasicProfile_User'. Because the Dependent Role
properties are not the key properties, the upper bound of the multiplicity
of the Dependent Role must be *.
I've found a way. Well, not purely a 1-1 relationship but a 1-0..1 relationship was what I was after, which, for all practical purposes is a one-to-one relationship.
If you ever fall into this trap like I described in my question, here's what you do:
1) Remove the Id field from the dependent table, in this case the UserProfile table. Therefore, do not give it a separate primary key.
2) Instead, mark the foreign key in the dependent table as its own primary key. In this case, mark the UserId field itself as the primary key of the UserProfile table.
In addition to these two, I assume, as I outlined in the question that you've got a primary and foreign key relationship between the authority (the User table in this case) and the dependent table (the UserProfile table in this example).
So, you new table structure should look like this:
User
------
Id
UserProfile
-------------
UserId (foreign key, and also the primary key of this UserProfile table)
Stuff
Entity Framework will then recognize this 1-0..1 relationship.
I'm trying to workout the best database design for the following :
1) I have two (or more) tables in the database. "Sports", "Teams", "Leagues", etc..
2) Each of these tables can have a one to many relationship with another table in this case "Feeds"
The idea being that various database entities can each have a list of associated "Feeds"
It seems wrong to me to have multiple foreign key columns on the "Feeds" table, one for each of the tables (Sport, League, etc..), so my question is how best to model this?
It's worth mentioning that each feed can only belong to one of the other tables. A feed can't be associated with a "Sport" and a "League"
I've considered the following :
1) Add an additional column to each of the "Sport" "League" etc.. tables with a GUID.
2) Add another column to the "Feeds" table also with a GUID and populate this with the GUID from my other table, then query on this.
This would allow me to have multiple tables referencing the same column of the "Feeds" table but is this any better than having multiple nullable foreign keys, one for each table?
It is not a bad idea to have a foreign key pointing to Feeds in several tables. Foreign keys can be used to handle the 1:n relation (one-to-many).
It seems wrong to me to have multiple foreign key columns on the
"Feeds" table, one for each of the tables (Sport, League, etc..), so
my question is how best to model this?
Why do you think it is not a good practice, what would be the downside of this design?
Ok I have a master table which can be designed in two different ways, and I'm unsure of the best approach. I am doing model first programming in regards to setting up the database.
I have 5 tables so far.
Master table
Departments
Functions
Processes
Procedures
Which is a better way to handle the design?
Idea #1:
Master Table
masterId, departmentID, functionID, processID, procedureID, user1, date
Should I make it this way and then provide a FK from master to the departments table, functions table, processess table and procedures table?
Idea #2
Master Table
MasterID, departmentID, user1, date
This table will link to Departments table, which will then link to functions, which will link to processes which will link to procedures.
The master table will have a complete list of everything.
A department can have many functions.
a function can have many processes.
a process can have many procedures.
Which of the ways is best or am I just doing it completely wrong and someone can tell me thee or close to thee best way to create this diagram of tables and linking structure?
If you have the following criteria,
A master can have many departments.
a department can have many functions.
a function can have many processes.
a process can have many procedures.
Then you must use your second design idea. You only have one department, one function, one process, and one procedure key in your first design idea.
Master
------
Master ID
User
Date
...
Department
----------
Department ID
Master ID
...
Function
--------
Function ID
Department ID
...
and so on.
The primary key of each table is an auto incrementing integer or long.
The foreign keys are identified by name.