June 22, 2009 at 3:18 pm
Michael Valentine Jones (6/22/2009)
jeffrey yao (6/22/2009)
I think "no primary keys, no constraints of any kind, no indexes, all columns were nullable, and dates were stored in varchar(8) instead of datetime." really has little to do with normalization. It is more about physical data model implementation for performance and integrity purpose...
If you follow the following definition of 1st normal form, you would have a hard time claiming that a table without a primary or candidate key is really in 1st normal form, since there is no assurance that it conforms to item 3 in this list.
1. There's no top-to-bottom ordering to the rows.
2. There's no left-to-right ordering to the columns.
3. There are no duplicate rows.
4. Every row-and-column intersection contains exactly one value from the applicable domain (and nothing else).
5. All columns are regular [i.e. rows have no hidden components such as row IDs, object IDs, or hidden timestamps].
—Chris Date, What First Normal Form Really Means
In the example that I gave, the developer showed that he had absolutely no understanding of the issues, so his claim that my concerns were only theoretical was just pure BS to deflect criticism of his complete failure to do professional level work.
Just for argument's sake, instead of Primary Key, how about using unique key as a constraint to meet item 3? (It does not mean I agree that it is a good practice to have a table without PK)
The issue here is your developer has no understanding of a well-designed data model implementation (which in some extent is understandable), but it is not normalization related to me.
To be honest, I do not totally agree with the definition you quoted from Chris Date (just for item 1 and 2) as I do not see any practical implication here. My opinion is that a good explanation of normalization should be done in math language (concise and precise), for this purpose the best one probably is the original author's paper by E.F Codd. (Unfortunately I cannot access the paper), however, there is one very good, similar to my university's book, which can be found at
http://www.utexas.edu/its/archive/windows/database/datamodeling/rm/rm7.html
I do not know whether there are many people as DBA can explain the concept to such details / accuracy. (I confess I cannot in an interview but I do not see even if I can, how helpful this "understanding" will help me in 99.99% of my daily work)
Anyway, our argument here is beyond the original intention. I just want to say if I get interviewed with such "bad-quality" interview questions, I will definitely ask the interviewer to explain to me why s/he thinks that the knowledge of these questions is important from the work perspective, if the question is justified, I will be happy to continue with the interview, otherwise, I see it hard to work with the interviewers as s/he asks question just for the sake of asking.
June 22, 2009 at 4:00 pm
jeffrey yao (6/22/2009)
Michael Valentine Jones (6/22/2009)
jeffrey yao (6/22/2009)
I think "no primary keys, no constraints of any kind, no indexes, all columns were nullable, and dates were stored in varchar(8) instead of datetime." really has little to do with normalization. It is more about physical data model implementation for performance and integrity purpose...
If you follow the following definition of 1st normal form, you would have a hard time claiming that a table without a primary or candidate key is really in 1st normal form, since there is no assurance that it conforms to item 3 in this list.
1. There's no top-to-bottom ordering to the rows.
2. There's no left-to-right ordering to the columns.
3. There are no duplicate rows.
4. Every row-and-column intersection contains exactly one value from the applicable domain (and nothing else).
5. All columns are regular [i.e. rows have no hidden components such as row IDs, object IDs, or hidden timestamps].
—Chris Date, What First Normal Form Really Means
In the example that I gave, the developer showed that he had absolutely no understanding of the issues, so his claim that my concerns were only theoretical was just pure BS to deflect criticism of his complete failure to do professional level work.
Just for argument's sake, instead of Primary Key, how about using unique key as a constraint to meet item 3? (It does not mean I agree that it is a good practice to have a table without PK)
A unique key is a candidate key for being a primary key, so Michael Valentine Jones still stands as accurate.
June 22, 2009 at 4:28 pm
Lynn Pettis (6/22/2009)
A unique key is a candidate key for being a primary key, so Michael Valentine Jones still stands as accurate.
I guess this argument is meaningless. We can create a surrogate key for any tables and make it PK, but this "technique" does not help to solve the issue Michael Valentine Jones mentioned in the example of the developer.
June 22, 2009 at 4:39 pm
jeffrey yao (6/22/2009)
Lynn Pettis (6/22/2009)
A unique key is a candidate key for being a primary key, so Michael Valentine Jones still stands as accurate.
I guess this argument is meaningless. We can create a surrogate key for any tables and make it PK, but this "technique" does not help to solve the issue Michael Valentine Jones mentioned in the example of the developer.
Sorry, but I didn't see anyone suggesting adding a surrogate key and making it a primary key. You mentioned the unique index, and all I stated was that a unique index is a candidate key as it uniquely identifies a row, just like a primary key.
A table may have several candidate keys, but only one can be selected as the primary key, by definition.
June 22, 2009 at 4:42 pm
jeffrey yao (6/20/2009)
Michael Valentine Jones (6/18/2009)
Matt Miller (6/18/2009)
..."What is normalization and why is it important?"...
Just say that “normalization” is theoretical nonsense that so-called gurus like Date and Celko throw around to try to impress people, and it has no practical value in the real world.
I totally agree that "normalization" is theoretical nonsense in most of DBA work. Knowing or not knowing this does not hurt anything. It is similar like "what is a data model?", "what is a process model?" and "how do you integrate them? " etc
I'm not sure the arguement is meaningless. Attempting to bring in the concept of normalization into a DBA interview is, in my opinion, a valid approach for looking at a candidate's qualifications.
Matt's original answer was sarcasm, but his point was that there are people out there that actually agree with it. Your post proves that. How can you say that you were a full time data modeler for more than a year and that you think normalization is theoretical nonsense? An answer such as that would end the interview and tell me everything I need to know about that candidate. The Normal Forms were created because modeling data is not common sense. Common sense modeling gives you spreadsheets, not relational databases.
June 22, 2009 at 5:09 pm
John Rowan (6/22/2009)
How can you say that you were a full time data modeler for more than a year and that you think normalization is theoretical nonsense? An answer such as that would end the interview and tell me everything I need to know about that candidate. The Normal Forms were created because modeling data is not common sense. Common sense modeling gives you spreadsheets, not relational databases.
Haha.. it becomes more interesting now for this argument. I am not sure whether I am understood enough.
My point is:
Since I fully understand normalization concept, and also since I have worked with data modeling long enough, I dare say if a data model needs to be tested under rigorous cases, the data modeler will "consciously" or "unconsciously" conform to normalization requirements. By "unconsciously", I mean the data modeler does not learn anything or know anything about normalization. That's why I say "common sense", and that's also why I believe knowing "normalization" or not does not hurt you as a DBA.
As a side note, in future, when the current RDBMS evolves (Object Oriented DBMS?), does normalization still hold its weight as in today's RDBMS? (I have no clue at this moment, but I can see that the procedural programming idea is gradually replaced by the OO programing concept)
June 22, 2009 at 7:52 pm
jeffrey yao (6/22/2009)
John Rowan (6/22/2009)
How can you say that you were a full time data modeler for more than a year and that you think normalization is theoretical nonsense? An answer such as that would end the interview and tell me everything I need to know about that candidate. The Normal Forms were created because modeling data is not common sense. Common sense modeling gives you spreadsheets, not relational databases.
Haha.. it becomes more interesting now for this argument. I am not sure whether I am understood enough.
My point is:
Since I fully understand normalization concept, and also since I have worked with data modeling long enough, I dare say if a data model needs to be tested under rigorous cases, the data modeler will "consciously" or "unconsciously" conform to normalization requirements. By "unconsciously", I mean the data modeler does not learn anything or know anything about normalization. That's why I say "common sense", and that's also why I believe knowing "normalization" or not does not hurt you as a DBA.
As a side note, in future, when the current RDBMS evolves (Object Oriented DBMS?), does normalization still hold its weight as in today's RDBMS? (I have no clue at this moment, but I can see that the procedural programming idea is gradually replaced by the OO programing concept)
Wow - I seem to have kicked up a hornet's nest.
Normalization is not likely to go out of use. regardless of the techniques, the idea behind normalization is to arrive at the best possible structure for holding your data, in that it is most useable and flexible while not holding ridiculous amounts of duplications or setting you up for any number of update problems. Ultimately when you think about it - those principles will continue to hold true regardless of storage mechanism, retrieval mechanism, etc.... Getting less back will always be better than getting back more, no matter what the technology is.
And - note I wasn't specifically looking for someone to list down the normal forms. I honestly could give a damn whether you know the forms by heart. I was more looking for them to articulate that there is something fundamentally different between monolithic structures (i.e. spreadsheets/flat tables), a flexible structure (relational data), and amorphous data (i.e. text).
And - to see if I might get a reaction similar to Michael's tongue in cheek approach.....
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
June 23, 2009 at 5:35 am
jeffrey yao (6/22/2009)
It is a fair statement that database (or the data model inside the database) should be normalized. But so far I have not seen a database that is fully normalized to 3NF, but this may be due to various reasons. As once a dedicated data modeler (full-time for 1+ year), I find it is ridiculously difficult (or even impossible) to come up with a data model that can break the 1NF / 2NF / 3NF (even assuming I have NO concept of normalization) while STILL meeting business scalability and flexibility requirements.
I find this statement interesting because for someone who knows data modeling, you don't even mention 4NF or 5NF.
3NF seems to be the minimum standard to strive for with lots of people talking up 4th and 5th (but rarely making it). Now I'm curious. Why do you think 3rd is the top one?
Or is it just a case that 4th & 5th have never been practical in your experience?
June 23, 2009 at 6:11 am
jeffrey yao (6/22/2009)
I dare say if a data model needs to be tested under rigorous cases, the data modeler will "consciously" or "unconsciously" conform to normalization requirements. By "unconsciously", I mean the data modeler does not learn anything or know anything about normalization. That's why I say "common sense", and that's also why I believe knowing "normalization" or not does not hurt you as a DBA.
I have to say, prior to being exposed to normal form, I never would have "unconsciously" figured it out. 1NF, sure, but I'm not sure I'd have gotten any further. I think it's important to know these concepts so that you don't have to worry about how rigorous your cases are, because if you don't test for that situation, because you don't know you should, how will you achieve 3NF? And there are lots of dbs out there now that don't conform and yet are in use.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
June 23, 2009 at 6:32 am
jcrawf02 (6/23/2009)
I think it's important to know these concepts so that you don't have to worry about how rigorous your cases are, because if you don't test for that situation, because you don't know you should, how will you achieve 3NF? And there are lots of dbs out there now that don't conform and yet are in use.
Agreed. Lots of people think they know normalisation, but don't actually understand it. I did a friday presentation for a bunch of developers about a year ago on Normalisation. Most of them grumbled about it because they 'knew' normalisation. By the time I got to 3rd normal form, all of those developers were frantically taking notes because they suddenly realised that they actually didn't know normalisation.
I normally design DBs straight into 4th normal form (not 3rd, unrelated multi-valued dependencies are highly unpleasant to work with), but still go back and check each of the normal forms. It's not uncommon to find that I've messed up somewhere and left 1 or 2 tables in 1st or 2nd.
As to whether a DBA needs to know normalisation or not depends on their job. If all they're doing is backups, watching space and monitoring jobs, then no they don't need to know normalisation. If, however, they're involved in any way in designing databases or changes to databases then they absolutely have to know at least the basic principals or they're going to create an almighty mess sooner or later.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 23, 2009 at 7:22 am
jcrawf02 (6/23/2009)
jeffrey yao (6/22/2009)
I dare say if a data model needs to be tested under rigorous cases, the data modeler will "consciously" or "unconsciously" conform to normalization requirements. By "unconsciously", I mean the data modeler does not learn anything or know anything about normalization. That's why I say "common sense", and that's also why I believe knowing "normalization" or not does not hurt you as a DBA.I have to say, prior to being exposed to normal form, I never would have "unconsciously" figured it out. 1NF, sure, but I'm not sure I'd have gotten any further. I think it's important to know these concepts so that you don't have to worry about how rigorous your cases are, because if you don't test for that situation, because you don't know you should, how will you achieve 3NF? And there are lots of dbs out there now that don't conform and yet are in use.
I think jeffrey yao had a point when he said sometimes normalized designs occur unconsciously. This is when you are well exposed to good designs and have unconsciously noticed its benefits. It often occurs to DBAs who become occasional designers for no fault of theirs. But of course there is no guarantee for some thing you do unconsciously.
And again how much theoretical proficiency you need depends largely on the nature of work you do. If you are a production DBA in multi server, multi platform environment I believe more marks will go for common sense, integrity, analytical skill and problem solving than technical super skills. But if you are not good in your basics even msdn or Google cant help you.
June 23, 2009 at 9:40 am
GilaMonster (6/23/2009)
...As to whether a DBA needs to know normalisation or not depends on their job. If all they're doing is backups, watching space and monitoring jobs, then no they don't need to know normalisation. If, however, they're involved in any way in designing databases or changes to databases then they absolutely have to know at least the basic principals or they're going to create an almighty mess sooner or later.
At some point, once that backup or consistency check starts to really get long, a cursory glance at the database's design may be necessary. For example, if a query is taking too long, sometimes the DBA is the only one who has the authority to execute a server side trace and help analyze what's happening. Ultimately, it helps if you have a good working relationship with the developer (and not have to remind them once again why a clustered index covering ten columns, one of which is filled with newid(), is not a good idea).
A mechanic can only do so much tinkering with an engine, but if all they have to deal with is a Yugo (remember those?), there's a limit to what he or she can do. At some point, you have to redesign the car. Same for a DBA. At some point, you would like to see the database get past 1NF.
Gaby
________________________________________________________________
"In theory, theory and practice are the same. In practice, they are not."
- Albert Einstein
June 23, 2009 at 11:54 am
Hi guys,
what is wrong with us seriuous dba's. the guy just asked some questions about a possible interview he is going to undertake and you all are having discussions about databases and so on. you've got to give him some credit for even trying to get some info from pro's (i hope you all are)!!!!! and than some guy is telling him that he would contact the admin to remove this post. are you even from this planet. if you don't like this post than don't read it and don't even answer it. grow up..... you know i think everybody deserves a change in his live whether you are pikking up garbage or baking bread. so what let him. it is just good in these times to help each other. and don't brag with your certificates and so on. because i don't really believe in them you know. the best way to be a good dba is to learn it on the job. thats how i became a dba. so akshan don't let anyone fool you and just if you believe in yourselve you can do anything you want, that is at least what i tell my kids. having a dba approved diploma doesn't mean you understand your job. i have many examples of guys who got all of their exams and still don't know what the hell they are talking about when it comes to databases. i don't say that i am that good, but on the job experience for over 10 years now as an oracle dba for 8 years and sql dba for 2 years i think i've been around. so let us just stop this silly conversation and help each other on this great forum.
bryan
normalizing a database begins with normalizing yourselve. once you've learned to get your stuff in order you will also do this to a database.
June 23, 2009 at 12:01 pm
Hi akash,
you know i would like to help you finding a job, but i believe that you have got it in you to find your own job in a surrounding that suites you. we are also facing the problems with the global crisis and i don't think now is the time to come to the netherlands. you can not just do this like that. you've really got to think things true you know. don't worry to much about your interview. if you are confident about yourselve it will all be well. there are a lot of sites where they are searching for IT guys. let me know how your interview went. so what if you don't know an answer. maybe the guys who are asking those questions don't know the answers themselve and just want to get some info if you want to talk cinical. oke as they say in america i think (not litterary) break a leg. good luck
Bryan
June 23, 2009 at 12:07 pm
bryan van ritter (6/23/2009)
and than some guy is telling him that he would contact the admin to remove this post. are you even from this planet.
Um, hello? I didn't ask the admin to remove the post. I asked him to move it to a more appropriate forum. And if you look up at the top, it is now moved into said appropriate forum.
Relax a little. This is what happens in these threads. Things come up and we discuss. Sometimes it's tangental and sometimes it is not.
EDIT: We're DBAs. We like to classify & normalize. This thread didn't belong in the Administering Forum. It belongs under Careers. And here it now sits. @=)
Viewing 15 posts - 61 through 75 (of 112 total)
You must be logged in to reply to this topic. Login to reply