I have a "Groups" table, a "GroupMembers" table, and a "MemberType" table. In the "GroupMembers" table I have a foreign key for "Group", a foreign key for "MemberType", and a lookup field called "Member", which is a lookup to one of one of 3 tables: "JobTitle", "LaborDepartments", of "LaborSubDepartments".
Basically, members of the groups can come from one of 3 tables, so I added the "MemberType" column so I know which table the link comes from.
So I guess my question is: is this normal? Is there a better way to do this?
Just looking for other people experience. I hope the situation makes sense.
I am using SQL Server 2008.
Thanks,
Tim
in case anyone stumbles upon this, here is a good discussion of what I'm up against Foreign key referring to primary keys across multiple tables?
I should have searched better first.
Related
I need to build a simple forum (message board) as a school project. But I came across one problem. In the img above there are 2 tables: post and category, which have many-to-many relationship. I made a bridge table, which stores the postKey and categoryKey. Is it a bad practice to create a composite primary key from those 2 keys, or I need something like postCategoryKey? And what else should I improve?
On my opinion, there is no need for PostCategoryKey, due to it's only a relationship table and you won't accés it by postCategoryKey.
I would create the PK using the 2 others FK (postKey and categoryKey).
Hope it helps!
It depends, if you plan later on to add some extra metadata to postCategoryKey in a separate table, then it makes sense.
In your case - I'd go with a composite primary key and get rid of postCategoryKey
You will have to make postKey and categoryKey not null and create a unique constraint on them anyway. That makes them a key for the table, no matter whether you call this the "primary key" or not.
So, there are three options:
Leave this as described with NOT NULL and the unique constraint.
Declare the two columns the table's primary key.
Create an additional column postCategoryKey and make this the primary key.
The decision doesn't really matter. Some companies have a database style convention. In that case it's easy; just follow the company rules. Some people want every table to have a single-column primary key. If so, add that PK column. Some people want bridge tables to have a composite primary key to imediately show what identifies a row. My personal preference is the latter, but any method is as good as the other actually. Just stay consistent in your database.
Forewarning, I am new to SQL. Sorry in advance if this question doesn't make sense or my concept of what I'm trying to do is just completely off.
That aside, I'm trying to add in multiple columns from varying tables into a set of columns in a centralized table, and ideally I'd do this simultaneously. Am I on the right track thinking this should be accomplished through joins? Maybe unions?
I'd appreciate it if someone could show me an example or point me in the right direction. Thank you!
Edit for clarification: I've got 3 tables. The old one, a new one, and a mapping table connecting the two,. I need to know how to populate the new table's columns simultaneously with the old table's values, via the mapping table.
I think maybe you should look more into Primary and Foreign Keys, and i suppose your table could have as foreign keys the other table primary keys, so this table would represent a relation from multiple tables.
Just a really quick question that I can't seem to find an answer for. I'm making these tables, and I have been told that every table needs to have some form of random unique ID, that is separate to the PK. My question is if I can relate two tables with UID/FK in the same way you would PK/FK.
Is this bad practice? What are the advantages/disadvantages?
Your "mentor" is right in a sense. In migrations and in BI star schema DWH's, it's best to come up with a new UID.
The reason for this: when joining like tables together, it's possible to have primary keys that are matches, or different formats.
Though, as others have said, it isn't necessary. Just best practice when joining data in a BI environment.
Hope that helps.
Is there a way to map one of the the columns contents of a MySQL table to an enum on another table in MySQL? I thought this would be a no brainer, but there doesn't seem to be any info that I can find on the subject.
Any advice or help on this matter would be cool and if it's not possible, does anyone know of an internal reason why it wouldn't be possible?
Best regards everyone :)
Gary
The enum type is handy as a one-off, but it doesn't scale well to multiple tables and isn't standard SQL either.
Best thing to do here is to use normal tables and relations:
Define a new table to hold the list of possible values; let's call it Master1
In the other two tables (let's call them Table1 and Table2), don't make the field an enum; just make it a normal field with a foreign key relation to Master1.
The foreign key relation will do the job of restricting to a list of possible values; and because foreign keys and relations are absolutely standard SQL, this approach will have other benefits - for example reporting tools can recognise the foreign key and understand how to use the related data.
If it doesn't do it, don't do it
Surely you just want a table of possible keys and then a foreign key mapping to that.
If you want a table with possible enum values and restrictions, go for groupings via another table or a groupid in the same table (if group members are unique).
Smells like table-stink though JOIN wise. Maybe best doing this in a stored procedure or in the app code and mapping it to a native value?
Hi I'm using ms2005 for a simple calendaring system.
We have three 'legacy' tables: Groups, Units and Staff.
I need to give each record in the tables a unique identifier (carrying across all 3 tables).
What would be best way to approach this? I am using NHibernate and was was wondering whether that could do it for me.
Anyway, any nods in the right direction much appreciated.
The usual practice is to create a surrogate primary key on each table using an int with IDENTITY(1,1).
If you need a unique values across systems then use a UNIQUEIDENTIFIER column (GUID).
Are you saying that the same identifier shouldn't appear in more than one table? That would be a fishy assertion that would suggest that more discussion is needed.
It would be a "Bad Smell", in a refactoring sense.