Ryan George (1/30/2014)
it is really interesting to hear. In a table, two prmary keys.
but this is a question which i got for an interview
i had options too.
as per the requirement, it is asked to create a table with two primary keys. how can we implement the same
(composite Primary key /
One primary key and one Unique key /
one primary key and unique key with NOT NULL constraint /
None of the above)
Thanks for the immediate response.
I feel your pain and I hate written questions like that and that's why I'd never be able to pass a test. I do, however, love such questions in an interview because they give me the chance to shine.
By definition and by design and as the others have stated, you cannot have two Primary Keys on a table. If you try to create a second real Primary Key on a table, it will give you an error (as the others have already stated).
That, not withstanding, I frequently do have the need to have a Primary Key and another key that could be used as a primary key on many of my tables and that answer is one of the 3 other answers on the list of possibilities you provided. So, now we have to guess... did the person that wrote the question understand that there truly can be one and only one primary key and he just wrote a question trying to trick you or is he someone that thinks that other kind of key is considered to be a Primary Key? Or is it a test of your interpretive capabilites to see if you understand that a lot of people don't know you can only have one real Primary Key on a table and what you would do about it if asked such a thing in real life?
If it's a written test that a human would review, I'd give the obvious answer that you can only have one and only one Primary Key for a table but I'd also write a small paragraph that you can also have a ALTERNATE KEY that could
be used as a Primary Key if there wasn't one already and then I would identify which answer that one was.
If it's a test to be graded by machine, I'd go with the technically correct answer and argue it to the max if I got it wrong.
If it's a question during an interview, then it's "discussion time" where you'd explain all about PKs, AKs, and their relationship with FKs. That's what interviewers look for when they ask questions. Do you know the subject well enough to spontaneously add facts, uses, and methods or are you just "book learned".
Remember, requirements in real life are rarely technically correct and THAT might be what they were actually looking for. A lot of people don't understand that "Before you can think outside the box, you must first realize... YOU'RE IN A BOX!" :-)
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair
How to post code problemsHow to post performance problemsForum FAQs