The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
That's about 1/3 the cost of a Raspberry Pi with a case, and a 32GB thumb-drive to boot from. Splurge and explore.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
I'm assuming you are talking about poorly gathered requirements.
Yes, but not just.
I've inherited a database and has been given the task of making it work according to new intentions.
And while it's actually quite fun most of the time, I would at other times find it even funnier to meet the original designer and teach him the virtues of normalization using a bundle of nettles.
The biggest problem is that he didn't have the domain knowledge to use the correct keys.
Then again, he's been using a surrogate key (identity) for a year table. Yes, it has two columns (YearID, Year) .
FORMAT(y.Year, '0000') + '-' + FORMAT(m.Month, '00') + '-' + FORMAT(d.Day, '00') AS OrderDate
FROM SalesOrder o
JOIN Year y ON y.Id = o.YearId
JOIN Month m ON m.Id = o.MonthId
JOIN Day d ON m.Id = o.DayId