- Feature Articles
- CodeSOD
-
Error'd
- Most Recent Articles
- Named And
- It's About Time
- Scrollpocalypse
- Fast Quick
- 12345
- Said Different
- Ai Dios Mio
- Unrewarding
-
Forums
-
Other Articles
- Random Article
- Other Series
- 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.