- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Edit Admin
I half-suspect that's auto-generated code. The rule says "When connecting two tables, make sure there's a FK constraint between them so there can't be orphan records". So when the dumb SQL generator code was told to connect table A to table A, it mindlessly added the appropriate FK constraint.
But where's the fun in that? Better to think it was a clueless self-taught noob. Or more likely somebody who took, passed, but understood none of, Databases 201.
Edit Admin
I agree on the autogenerated but I think this is probably the result of someone accidentally dragging the PK column while using a table/diagram designer like the one that has been included with SSMS since forever, the same one that produces names like
PK__Configur__F6E145D05992BA46andDF__Configura__KtCal__7F23583C.Edit Admin
The only smart thing I've ever done is realized that I'm not as smart as I think I am, so I'll ask all y'all if my answer to the above is correct: the proper way to handle that is to have a separate mapping table with an [EmployeeID] column and a [ManagerID] column.
Yes? No?
Addendum 2026-11-05 09:27: . . . both of which are foreign keys to the [Employee] table.
Edit Admin
in my opinion it is a bad thing bc having a manager is a bad thing... they're the ones responsible for having this kind of code in 99% of the cases
Edit Admin
"..the proper way to handle that is to have a separate mapping table with an [EmployeeID] column and a [ManagerID] column." "having a manager is a bad thing... they're the ones responsible for having this kind of code in 99% of the cases"
I agree, having a separate mapping table would be my choice, but that leads to the ugly possibility of not just having a manager, but having multiple managers shudder
Edit Admin
@n9ds - Apparently you are young enough to have missed the "matrix management" craze of the 80s.
Edit Admin
Yes? No?
The proper way to do that is to have a field on the employee record that points to a manager_id field in a MANAGERS table. That table has a bunch of demographic info about the management position - not the employee who is the manager - but it contains employee_id that maps back to EMPLOYEES. There should not be any foreign keys here because the person who is the Big Big Boss does not have a manager. If there is a FK constraint from EMPLOYEES.Manager_Id to MANAGERS.Manager_Id the CEO's employee record cannot be added because their Manger_Id would be null. However, there should be a FK constraint from MANAGERS.Employee_id (the employee number of the manager) back to EMPLOYEES.Employee_id so that no record can be inserted into the MANAGERS table with an invalid employee number for the manager.
EMPLOYEES should have PK as Company, Employee_Id and MANAGERS should have PK as Company, Manager_Id. It is debatable as to whether the PK suffices as a proper constraint; I have seen situations where EMPLOYEES has a unique primary index AND a constraint defined as the exact same unique index. Whether the additional constraint is required is debatable, but they are redundant. The main difference is a PK cannot have NULL values and is a clustered index; a constraint can have one (or more, depending on the DB) NULL values and is non-clustered, taking up more space.
Addendum 2026-11-05 11:25: EDIT: "There should not be any foreign keys here because the person who is the Big Big Boss does not have a manager."
I meant there should not be FK constraint on the employee record to the manager table. There absolutely should be a FK constraint on the manager table's employee id back to the employee table.
Edit Admin
Thinking about it, I think someone can have multiple positions at a job (not at all common, but still possible), and each position will have their own manager.