- 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
Admin
i suppose Jay J was Abrams and vacancy was not just Enterprise but USS Enterprize NCC-1701
Admin
Where's the WTF? He was born that day, it is a holiday! Or maybe it's a special maternity ward holiday, nobody can give birth that day?
Admin
The "developer" that tested this is apparently born on a workday
Admin
Um, birthdate on a job application? In the U.S. that is grounds for a lawsuit.
Admin
Notice to all Employees, We apologize but we have to cancel Christmas as a new hire was born on that day and our current business rules prevent us from having any employees born on a holiday. Please return to work as normal. Thank you, have a nice day.
Admin
TRWTF is of course the Hungarian notation in dteBirthDate, needlessly repeating the dateyness;. The other RWTF is using the variable name in an error message instead of a user-friendly description
Admin
Is this the same Jay J that had over 3 years experience with Microsoft Dynamics AX in https://www.thedailywtf.com/articles/Make-It-Work 🤔?
Admin
With so many religions in the world, every day is a holiday someplace. Also, there is the "problem" of some calendars (like the Islamic, for instance) that do not have corrections for the difference between themselves and the globally used Gregorian calendar. Holidays on these calendars move continually so this would be a WTF as a solution.
But I do like it!
Admin
My family would be in trouble. My sister, and my brother-in-lay were BOTH born on Christmas day. Not only that, but the same year. Go figure.
Admin
Blunt instrument method of preventing hiring programmers with a messiah complex?
Admin
When you re-e-eally want to become a part of IT-industry, but the IT-industry itself doesn't want you to be a part of it ¯_(ツ)_/¯
Admin
Or Easter eggs in your code
Admin
My boys were both born on the same day too. Now I can't remember exactly what system, some type of health insurance, I was entering data for. The electronic form would NOT let me enter two children with the same date of birth. Soooo, in that system my twins are born one day apart (go figure that one out) and we hoped this wouldn't lead to any issues (fortunately it didn't).
Admin
My twin younger brothers were born on different days, different years even; one was born at 23:59 on December 31st, the other at 00:01, January 1st. A firework fell into our yard the evening of the 31st and burned up a tree near the house, the stress of the ordeal caused my mother to go into labor.
Admin
This is common and attributed to the camp of developers that believe that unique keys should be a compound key of meta data, in this case birth date and last name. I know the system you are talking about. unique keys never ever ever should be compound meta data and anyone who thinks they should be should study this example. There are compound natural keys and there are truly unique random keys and both should exist because they provide different purposes. Compound natural keys should not be unique because since they are natural you can't guarantee uniqueness, but they are how we, as people, look for and identify data. Unique keys have zero relationship to the data other then the arbitrary assignment by a computer system for the sole purpose of that system being able to uniquely identify that particular record to the exclusion of all others. In additional, the elements of a compound key can and really should be view-able by a user where unique indexing keys should never be displayed because then people want to attach additional meaning to them, and that is bad.
Admin
I'm sorry, but this is a horrible answer on a number of fronts. Also, blanket statements that applying a compound natural key is always a bad idea means you haven't paid attention to the standard database developer mantra: "It depends".
It depends.
There are plenty of real-world cases where a compound natural key isn't just a good idea, it's the best idea.
Your patient example is one example. Yes, someone should not uniqueify data by lastName + DOB, nor lastName + DOB + firstName, etc.. But that is one example you provided, and a basic example at that.
Admin
So this is what Jay's strong sense of what jobs are promising leads to.
Also, "Were there a picture, this could be an errord": yes, which is what Jay's friend could have done to save Jay's time. Or was the experience so hillarious that the friend thought Jay better had it first hand?
(I know, probably both the elements are not in the story submitted originally.)
A tale from the interview that never was?
Just nitpicking. Love to see it when programmers make assumptions on dates, names, and other things which they think they know well. Even Face***k made idiotic assumptions about names some years ago (I don't know what they do now).
Admin
Your brother-in-lay is born on Christmas? That's enggravating!
Admin
Well no, certainly not. They hold great respect for the Grand Tradition of the Ritual of the Singing of the Happy Birthday Around the Desk. They can't do that if the employee is not in the office on that day nobody's ever there on that date.
Admin
For a second there, I thought you were saying your sister and brother-in-law are twins, which would mean that you married your sister?!
Admin
The real wtf is that you get an „500 - internal server error“ when trying to log in with github or google on mobile, but if you are already logged into those services, if logs you in anyway if navigate back to the comments :)
Admin
Reminds me that recently there were reports about a lot of people, whose names happen to be or contain swear words when interpreted in some language, have a hard time registering in online services under their true name. Googling for „register rude name“ only brings up a 2002 article on MS Passport (that was a thing?), but I remember recent articles on this happening with online shops. And I think it affected Twitter or Facebook too. And examples were given of moderators forcing a rename, when the person used their real name in some game or forum.
The cause isn’t directly related, but the symptom is.
Admin
Then you did not even read what I wrote. I did not say compound keys are bad, I said only using compound keys are bad, yes some blanket statements are valid like trying to haul a ton of dirt in a hatchback is bad, there is a tool for that and it's a truck. Read again, I said there was a use for compound keys and it is a usage that truly unique keys cannot fulfill. I'll say it again even more simply, YOU NEED THEM BOTH for a fully efficient system. Once you realize that, use each for their strengths and do not try to get rid of one because the other is good enough. Users should not find meaning in a truly unique key and they will be hard to remember anyway. Systems should not ever rely on compound keys for uniqueness because you actually can't guarantee it, trying to do so only gets you into the index lottery, at some point you will have a collision. Hence no two babies can be born on the same day at the same hospital to the same family. That is a natural key that should never have been thought of as unique.
Admin
So only one could get a job at this place? Wow -- there must be a discrimination suit in there someplace.
Admin
I disagree with "[s]ystems should not ever rely on compound keys for uniqueness because you actually can't guarantee it" — like Barf4Eva said, "it depends". In this example birth date and surname obviously isn't good enough; if you extend your thought to the logical data domain then how could you ever really prove that somebody is who they say they are? The only thing that even comes close to a reliably unique key for an individual human being is their genome, and even that isn't technically good enough. So yes, a surrogate identifier would be a way of resolving that issue.
But what if your data domain is, for instance, geographical points on Earth's surface? If your domain is well-defined (latitude and longitude), then there's no need to assign a surrogate to each permutation of latitude and longitude; we're not going to discover a new bit of the Earth's surface that we hadn't noticed before that unhelpfully shares the same coordinates with somewhere we already knew about and that a surrogate key would have saved us from. Conversely, if you need to extend your data domain, e.g. into three-dimensional space, and/or incorporating points in or ranges of time, there are key systems for that too.
Admin
Don't get me wrong, I agree with almost everything you said, but you can definitely enforce uniqueness on a natural key and thus use it as a unique identifier. So help me Codd etc.
Admin
Your coordinate example is also flawed because coordinates are floats and floats aren't precise, hence uniqueness is impossible. I'm happy to hear another example of a natural perfectly unique key, but so far nothing has been proposed and I haven't come up with anything on my own to disprove KattMan. Even things like SSN, email, phone, VIN aren't perfectly unique in the real world. Furthermore, many to many mapping tables need a unique ID too because sometimes you can have the same mapping twice, or another attribute is needed for the mapping itself.
You always need a computer generated unique ID for each record, period.
Admin
I disagree. I've seen way too many hilariously avoidable catastrophes caused by assigning a surrogate key "just because". But really, it depends on what you're trying to identify — with data, you're generally trying to identify something in the real world (for a given value of "real"), whether it's physical or not. A lot of people lose sight of that and only think about identifying the record, which is important in its own right, but dangerous to get confused with identifying the entity that you're attempting to represent. For instance, you say that coordinates are floats — they're not. Floating-point arithmetic is essentially a technical implementation detail pertaining to computers. We've had latitude and longitude longer than we've had computers. You might have a piece of software that happens to use a floating-point data type to represent a coordinate, but that doesn't nullify the GPS system anymore than my executing DROP TABLE Country would initiate world peace.
Admin
Simple example from my last comment — a list of countries. Moving over to the technical side of things, which I've been trying not to do, in most databases I would never have a meaningless surrogate to identify a country, because we've got ISO 3166-1, which is an internationally-agreed-upon standard list of unique country identifiers. I make the alpha-2 code the primary key (and cluster key) for the Country table, and then any time I need to attach the concept of a country to something, I can use that code. Most people that encounter that data will know what it means when they see it, and those who don't can go and find out, either in my database or on Wikipedia or the ISO website or Google. If I use a 32-bit integer surrogate key instead, I've just doubled the amount of storage space for every single reference to a country (in SQL Server), my queries will request more resources than they need to, and if I don't then maintain a logical unique identifier (like, say, the ISO 3166-1 alpha-2 code) alongside the surrogate then I've also just introduced the ability for me to have two United States of Americas in my table.
Admin
point being — the theory behind normalisation is really to have a single authoritative source of data, which is entirely separate from the technical concerns. Sometimes, somebody else has done that work for you (like with ISO 3166). Other times, somebody else has done that work for you, but they were also an idiot and their work is broken (SSNs). If you've identified that you can't rely upon an external source to do their job right, then by all means you should do the job right yourself and move on.
But if I have my Country table like I mentioned above, and a third party sends me some data representing entities with a "country" property, but they've used the wrong country codes, — that's their problem, my data domain will reject codes that don't exist in ISO 3166 and happily accept ones that do exist but don't accurately reflect what the third party meant to send me.
Conversely, if tomorrow ISO revise the standard and decide that every country in the world, and all of their special use entities, have the code "ZZ" in ISO 3166-1 — the unique key I decided to use is no longer fit for purpose and I'm going to have to find something else. But a surrogate unique identifier wouldn't have helped me out of either of those situations, unless I violated several principles of relational data theory simultaneously.
Admin
You've already failed when you asked Crimeans what country they're in.
Admin
Apparently you are missing something here. Honestly, the ISO 3166 is the implementation of the Unique identifier I was talking about, it is the unique code used to identify the country, it is not the country itself nor is it a natural key these are numeric codes. Yes someone already provided the key for you that uniquely identifies these. I never said you could not adopt already proven unique keys, but these are unique keys and should not be presented to a user of your system, nor should they actually be used in a search. Someone isn't going to look for country 004 instead they are going to look for Afghanistan. SO thank you for proving my point without realizing I never said they had to be some 32 bit integer, they only had to be proven unique with no other purpose then to uniquely identify the record.
Admin
Experienced this over the years in their job app websites, with a LOT of different orgs, from small to huge (including Oracle, whose DB would crash half the time I submitted an app for a job). When applying you should bear in mind that the people who create these apps/sites are usually not the primary dev teams, so they usually have little bearing on how the org runs its s/w dev processes or the skill/experience of their devs. Sometimes such efforts are outsourced too.
Admin
To further explain and hopefully resolve the issues here. in the USA, we have state codes, for the state table we do not need a 32 bit integer, we already have a unique key in the state abbreviation, 2 character guaranteed unique generated by the system that owns that data (the USPS I believe) you can adopt that for the state table. Now for the People table, the state ID is what is used to link to the state information, not the full state name, that would be stupid. but what you cannot do reliably is use the state id as the natural key to the person, so you go deeper, add a city ID, nope not good enough, add the street name.. house number.. last name.. no first name.. no because we name people badly and John can have a junior. your natural key here is not anywhere near good enough and it expands out for more then some 32 bit integer would be in order to reliably and uniquely identify a person. You can't even use GPS coordinates as part of this natural key because the coordinates are not unique to the person. This I think is where everyone that argues this point messes up. Within the domain, the key has to be unique. outside of that domain it is the unique key that is part of the meta data and should not be part of the unique identifier of that entity. You can still have all those natural keys that make it easy to look up, "Hey find me John Smith in this state in this city at this address" and get two hits and have the user pick one to look at, behind the scenes the system tracks that pick with the unique key with the user having no knowledge of this being used to track, they just care they have the right John Smith.
Admin
brother-in-lay
Admin
First, like others pointed out, the ISO country codes are hardly natural. Second, for performance, I would still go with an integer ID. It depends on implementation, I can imagine a database engine optimizing char(2) comparison to treat it as 16 bit integer for indexing, but that's not guaranteed. Whereas integer is fastest, always. Third, for consistency, if you consider that 99% of entities don't have an externally defined code like countries do, you're using an integer ID for those, you might as well use integer ID for countries, too. Fourth, the 2 letter code is in many cases useless data. Fifth, from code perspective, it's s lot easier to have a unified approach where all your classes share a common trait of having an internet ID, rather than having a zoo of string ID here, a pair of floats there, etc.
Going back to geo coordinates, floats are imprecise regardless of implementation. No measurement in the real world is precise. You wouldn't want to rely on it for database lookups. Second, implementation is important, most popular database engines don't support perfect equality even if you remove the problem of measurement precision.
Addendum 2018-12-04 16:12: Replace internet with integer. Also, for foreign keys, compound keys really start messing things up. I've seen tables with a 4-5 column unique key, and some sets of those columns were foreign keys pointing at other tables.
Admin
Funny you mention states. You can have a 2 letter code for USA, fine. What about other countries? Some are unitary, some federated. Inside states, what about counties? City names are unique inside a state, do we make the combination of name and state as the city's unique key?
This is why the rule should be, regardless of scope, industry, geographic coverage, localization, etc.., always use integer (and/or guid in rare cases) IDs. Even if you're USPS and you're working on the states table.
Admin
The rule should be (and is) "it depends". It depends on the data domain, the data, internal and external context, least astonishment, and performance. Set theory exists independent of computers, and the point at which they meet is where the design decisions get made.
Admin
I don't think you understand what I'm saying. If I was attempting to uniquely identify a person I probably wouldn't start with their location, because they might be on a train.
Admin
There's no good scenario that I've seen so far where anything other than a computer generated unique key is the best approach. I'd like to see one example!
Admin
Admin
Only if one is laying with (3) one's sibling, (4) one's significant other's sibling or (5) the significant other of a sibling.
This is a brother-in-lay, no legal connection required.
Admin
Funny thing is, we aren't even really talking about compound keys but composite natural keys, but whatever. Even if it we had used the right lingo from the start, and I'm sure you were referring to composite natural keys, it's bogus to think they never apply. I think your view is modeled by systems you've worked on, and perhaps you just haven't come across a good composite in your life that was natural. They exist... Dunno what to tell you.
Admin
I would argue those are natural keys. Others are perhaps pointing out what they think is meant by the word "natural", not the actual intent from DB theory. A code from an ISO list is perfectly cromulent as a natural key. This is a code, agreed on in the real world, not internal to your system. That is natural. It's out there in the "wild", for all to consume and use.
Admin
I would argue those are natural keys. Others are perhaps pointing out what they think is meant by the word "natural", not the actual intent from DB theory. A code from an ISO list is perfectly cromulent as a natural key. This is a code, agreed on in the real world, not internal to your system. That is natural. It's out there in the "wild", for all to consume and use.
Admin
Again you aren't listening, Re-read everything I have said but this is the last time. I never said they don't 'apply, I actually said they apply just as much as purely unique keys do, they just have a different purpose. You need both, pretty much nearly all the time. Which key you need for a particular purpose, well that depends, but you data should have both to leverage to strengths of both, unique internal identification, and ease of searching based of those keys.
Admin
What I believe is being said is that it is no harder/easier for a human to identify a person than a computer. This being the case, any key good enough for humans is also good enough for computers. If a human looks for a person by last name and date of birth, they will have to resolve the ambiguity too, somehow. Whatever that resolution is can be added into a key and you're done.
Admin
Is Hanukkah cancelled?