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.
Related
Good Morning,
in the design of a database, I have a table (TabA's call it) that could have relationships with four other tables. In the sense that this table can be connected both with the first of four, and with the second, and the third to the fourth, but could not have links with them; or it could have one (with any of the tables), or two links (always with two of any of them), and so on.
The table TabA I added four fields that refer to the four tables which could be "null" when they do not have any connection.
Wondering is this the kind of optimal design (say the four fields in the TabA) or you can make a better design for this type of situation?
Many thanks for your reply.
dave
In answer to the question and clarification in your comment, the answer is that your design can't be improved in terms of the number of foreign key columns. Having a specific foreign key column for every potential foreign key relationship is a best practice design.
However, the schema design itself seems questionable. I don't have enough information to tell whether the "Distributori_[N]_Livello" tables are a truly hierarchical structure or not. If it is, it is often possible to use a self-referential table for hierarchical structures rather than a set of N tables, as the diagram you linked seems to use. If you are able to refactor your design in such a way, it might be possible to reduce the number of foreign key columns required.
Whether this is possible or not is not for me to say given the data provided.
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.
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.
Relationship tables mostly contain two columns: IDTABLE1, and IDTABLE2.
Only thing that seems to change between relationship tables is the names of those two columns, and table name.
Would it be better if we create one table Relationships and in this table we place 3 columns:
TABLE_NAME, IDTABLE1, IDTABLE2, and then use this table for all relationships?
Is this a good/acceptable solution in web/desktop application development? What would be downside of this?
Note:
Thank you all for feedback. I appreciate it.
But, I think you are taking it a bit too far... Every solution works until one point.
As data storage simple text file is good till certain point, than excel is better, than MS Access, than SQL Server, than...
To be honest, I haven't seen any argument that states why this solution is bad for small projects (with DB size of few GB).
It would be a monster of a table; it would also be cumbersome. Performance-wise, such a table would not be a great idea. Also, foreign keys are impossible to add to such a table. I really can't see a lot of advantages to such a solution.
Bad idea.
How would you enforce the foreign keys if IDTABLE1 could contain ids from any table at all?
To achieve acceptable performance on joins without a load of unnecessary IO to bring in completely unrelated rows you would need a composite index with leading column TABLE_NAME that basically ends up partitioning the table into sections anyway.
Obviously even with this pseudo partitioning going on you would still be wasting a lot of space in the table/indexes just repeating the table name for each row.
Isn't it a big IF that you're only going to store the 2 ID fields? If I have a StudentCourse (or better yet Enrollment) table that has StudentID & CourseID, but wouldn't EnrollmentDate go in this table as well since not all students enroll on the first day of class. Seems like a bad idea to add this column to an already bloated table where most records will be null.
The benefit of a single table could be a requirement that the application has the ability to allow user/admin to create these relationships with data (Similar to have a single lookup or reference list table) and avoid having to create a new table to address these User Created References. Needing dynamic querying may benefit as well. An application that requires such dynamic data structure requirements might be better suited for a schemaless or nosql database.
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?