Efficient table design



  • I added a new feature to our system. It was one table that had about 50-ish nearly identical types of records, with the type being the only differentiator.

    Our DBAs tried to optimize it for performance.

    Their solution? 50ish identical db tables, complete with identical indices, constraints, PKs, FKs, etc, with the only difference being the name of the table:

    AAAEvent, BBBEvent, CCCEvent, ...

    The stored procedure that I wrote to insert records into the table simply took a list of records and forall'd them in one bulk insert.

    The DBAs created 50-ish temp arrays (minus the type field ), spun through the argument list, and with a huge if-else if statement put common types into the subordinate bucket-arrays, and then forall'd each bucket into the db.

    They did it wrong and blew up our application. When I showed my boss why, he called a meeting with them. They insisted their way was more efficient.

    I inquired as to what would happen on the next three projects that would entail changes to my original table? You'll need to deal with that!

    So now, you can no longer do: select * from OneTable where type in (1,2,3,...); you need to query n tables, add your own indicator to each so the target code can differentiate the records, and then join the whole mess together.

    I think the bigger WTF is my boss for his utter lack of spine.

     



  • Ok I'm starting to think you're just making all this up.



  • Biggest WTF in my opinion: DBA changing the design of the database. As far as I know and understand the term, a Database Administrator administrates (shocker), investigates and passes out advice, he/she does not alter a vital part of the application framework just to fulfil performance requirements.

    WTF. Just thinking about this actually happening puts me in shock.


  • ♿ (Parody)

    I love the smell of premature optimization gone wrong!



  • This is easily fixed.

    CREATE VIEW OneTable AS
    SELECT 1 AS type, * FROM AAAEvent
    UNION
    SELECT 2 AS type, * FROM BBBEvent
    ...
    UNION
    SELECT 50 AS type, * FROM AAAXXXEvent



  • @blakeyrat said:

    Ok I'm starting to think you're just making all this up.
    Sorry, but it's true.

    I changed my code to use dynamic sql so the damage is confined to two small methods and a single stored procedure.



  • @snoofle said:

    @blakeyrat said:

    Ok I'm starting to think you're just making all this up.
    Sorry, but it's true.

    I changed my code to use dynamic sql so the damage is confined to two small methods and a single stored procedure.

    I believe the story. I don't believe you work at this place and don't leave.

    I think what you're doing is aggregating stories from other people and claiming they all happened to you. #conspiracytheory



  • @erikal said:

    Biggest WTF in my opinion: DBA changing the design of the database. As far as I know and understand the term, a Database Administrator administrates (shocker), investigates and passes out advice, he/she does not alter a vital part of the application framework just to fulfil performance requirements.

    You know and understand correct.

    Furthermore, any PL/SQL dev making structural changes to the schema should also harmonise access layers (views/SPs) so that any connecting application should be unaware of these changes - the only noticible change should be the end-user viewing a more responsive application.

    Yep.. that's not the real world for many environments...

    @snoofle: have you pressured your manager into the ramifications of poor change control? i.e.: has your manager accepted that DBAs permitted to make whatever changes they desire (and whenever) without proper stakeholder analysis and communication of intent could will result in costly delays to your deliverables (and increased project costs for the boss)...? It does sound rather like he's bowing to their whim without fully understanding how it affects him.



  • @snoofle said:

    Our DBAs tried to optimize it for performance.
    Is there perhaps a language-barrier there? When a DBA says 'I'm going to optimise performance', what they normally mean is 'hit me in the head with a lump of wood until I stop breathing'.



  • @snoofle said:

    I added a new feature to our system.

    I saw "snoofle" and this sentence, and my brain immediately said "Oh noooooo!"

     



  • @snoofle said:

    It was one table that had about 50-ish nearly identical types of records, with the type being the only differentiator.

    If there is 50-ish types of something, I'd usually expect there to be a couple more next week. Perhaps you could insist that the list of types has to be dynamic or at least help a few types crop up, so DBAs would have to maintain that premature optimization.



  • @Bulb said:

    @snoofle said:
    It was one table that had about 50-ish nearly identical types of records, with the type being the only differentiator.
    If there is 50-ish types of something, I'd usually expect there to be a couple more next week. Perhaps you could insist that the list of types has to be dynamic or at least help a few types crop up, so DBAs would have to maintain that premature optimization.
     

    Aha, but re-read the OP and you'll find:

    I inquired as to what would happen on the next three projects that would entail changes to my original table? You'll need to deal with that! 

    It is now poor Snoofles problem apparently. Which reminds me: if that is really true, then you have all the power to change it back as part of the next bugfix you need to do.



  •  Snoofle:  Let me guess they will suggest a partitioned view.... If so check contraints are going to be vital because typically a query optimizer will be able to use those contraints and just ignore certain tables entirely. Sounds like they just learned what normalization is.

    erikal: I'm a devloper and a dba.  As DBAs we do need to understand at a deep level how the schema effects performance.  We also need to understand SQL code at a deep level.  Your SQL actually has an impact on the performance of the server as a whole.  I spend a lot of time showing developers how to write and maintain efficient code, how to analyze an execution plan, etc. Sounds like Snoofle's dbas Don't really understand things.  Unfortunately many dbas don't truly understand normalization and go way out into left field, like in this case!  A good dba is 50% sysadmin and 50% developer.  I find myself as a dba often querying the dmv's to gather permance metrics and to troubleshoot memory, io, and cpu issues.

    You are right though that a DBA, especially one without a good bit of developer knowledge, shouldn't just be changing your structure willy nilly. They should talk with you about it to learn more and provide some insight.  Slam them for violating change control procedures and not knowing what should be basic knowledge.



  • @All:

    My boss is afraid of conflict with anyone because his boss is nuts and will fire anyone who makes waves (and can't back it up). As a general statement, I tend not to run my mouth in the office unless I'm certain I can back it up.

    I generally write my SQL to get my point across and then ask someone who is well versed in SQL to make it better (databases really aren't my strong suit). In this case, our DBAs are idiots, but they're militant that things be done their way, and developers have no say. If you argue, they complain to their boss' boss who complains to my boss' boss who then targets you. As such, I just sigh and bill for the time. And post it here.

    As for leaving, I will, at some point, get bored and move on. But I've learned over the years that every place you go has it's share of WTF, so leaving won't necessarily make things better for me. For now, I get to come and go as I please, and that's worth a lot to me.

     



  • @snoofle said:

    @All:

    My boss is afraid of conflict with anyone because his boss is nuts and will fire anyone who makes waves (and can't back it up). As a general statement, I tend not to run my mouth in the office unless I'm certain I can back it up.

    I generally write my SQL to get my point across and then ask someone who is well versed in SQL to make it better (databases really aren't my strong suit). In this case, our DBAs are idiots, but they're militant that things be done their way, and developers have no say. If you argue, they complain to their boss' boss who complains to my boss' boss who then targets you. As such, I just sigh and bill for the time. And post it here.

    As for leaving, I will, at some point, get bored and move on. But I've learned over the years that every place you go has it's share of WTF, so leaving won't necessarily make things better for me. For now, I get to come and go as I please, and that's worth a lot to me.

     

    Unfortunately its a common occurance that DBAs blame devs and devs blame DBAs.  DBAs and Devs should be good friends working together to solve issues. It sounds like your dbas are very junior based on their idea of way over normalizing. 

     From all your past stories it seems like politics rule your workplace. For that you have my condolences.

     



  • I would recommend they build a huge view on top of it where the first column indicates the type based on the table the row comes from:

     SELECT 1 AS type, AAAEvent.* FROM AAAEvent UNION ALL

     SELECT 2 AS type, BBBEvent.* FROM BBBEvent UNION ALL

     etc.

    And then they could build your original table, but without data, and use a trigger to insert the data in the "prope" table.

    Or they could just partition it (might cost money, though).



  • @galgorah said:

    erikal: I'm a devloper and a dba.  As DBAs we do need to understand at a deep level how the schema effects performance.  We also need to understand SQL code at a deep level.  Your SQL actually has an impact on the performance of the server as a whole.  I spend a lot of time showing developers how to write and maintain efficient code, how to analyze an execution plan, etc. Sounds like Snoofle's dbas Don't really understand things.  Unfortunately many dbas don't truly understand normalization and go way out into left field, like in this case!  A good dba is 50% sysadmin and 50% developer.  I find myself as a dba often querying the dmv's to gather permance metrics and to troubleshoot memory, io, and cpu issues.

     

    You describe the ideal DBA/database driven application developer here. You do not exist, so what are you? Alien?

     



  • @erikal said:

    @galgorah said:

    erikal: I'm a devloper and a dba.  As DBAs we do need to understand at a deep level how the schema effects performance.  We also need to understand SQL code at a deep level.  Your SQL actually has an impact on the performance of the server as a whole.  I spend a lot of time showing developers how to write and maintain efficient code, how to analyze an execution plan, etc. Sounds like Snoofle's dbas Don't really understand things.  Unfortunately many dbas don't truly understand normalization and go way out into left field, like in this case!  A good dba is 50% sysadmin and 50% developer.  I find myself as a dba often querying the dmv's to gather permance metrics and to troubleshoot memory, io, and cpu issues.

     

    You describe the ideal DBA/database driven application developer here. You do not exist, so what are you? Alien?

     

    I am the eternal possum. And I can assure that while certainly elusive, I definitely exist

     



  • 1. Add a new column to every table, saying it is a new field that every type needs.

    2. Populate this new column with something that actually represents the type.

    3. Only use one type.

     Problem solved.



  • @galgorah said:

    @erikal said:

    @galgorah said:

    erikal: I'm a devloper and a dba.  As DBAs we do need to understand at a deep level how the schema effects performance.  We also need to understand SQL code at a deep level.  Your SQL actually has an impact on the performance of the server as a whole.  I spend a lot of time showing developers how to write and maintain efficient code, how to analyze an execution plan, etc. Sounds like Snoofle's dbas Don't really understand things.  Unfortunately many dbas don't truly understand normalization and go way out into left field, like in this case!  A good dba is 50% sysadmin and 50% developer.  I find myself as a dba often querying the dmv's to gather permance metrics and to troubleshoot memory, io, and cpu issues.

     

    You describe the ideal DBA/database driven application developer here. You do not exist, so what are you? Alien?

     

    I am the eternal possum. And I can assure that while certainly elusive, I definitely exist

     

    A DBA at a former workplace (at a major bank) was just like that. He really had the DB2 database under control, and he was a great help for us developers to improve our SQL if it didn't perform. He questioned our table designs, but he accepted good reasoning on our part. He didn't like denormalized designs, but would accept them if performance dictated them.

    Several times I send him a query asking him if he could improve its performance. He usually responded within hours with better formulated statements or suggestions for improved indexes that would improve performance by factors of 100.

    It was a pleasure to work with him. I still miss him. Ahhh! Good times! I would still marry him anytime... :-)



  • @TheRider said:

    A DBA at a former workplace (at a major bank) was just like that. He really had the DB2 database under control, and he was a great help for us developers to improve our SQL if it didn't perform. He questioned our table designs, but he accepted good reasoning on our part. He didn't like denormalized designs, but would accept them if performance dictated them.

    Several times I send him a query asking him if he could improve its performance. He usually responded within hours with better formulated statements or suggestions for improved indexes that would improve performance by factors of 100.

    It was a pleasure to work with him. I still miss him. Ahhh! Good times! I would still marry him anytime... :-)

    This is the definition of a good DBA.  Now keep in mind I wouldn't give a dev sysadmin access to a server.  But I would give them the access that they need as they need it. This way what the app actually needs can be documented easily.  This way the app will have a better chance of not breaking as it is moved between environments.  Usually this involves a discussions with the dev(s) about the application.  We're supposed to be friends not enemies. Heck you want an instance all your own.  Sure! it's no prob.    

     



  • @galgorah said:

    @TheRider said:
    Ahhh! Good times! I would still marry him anytime... :-)
    This is the definition of a good DBA. 
    I must say then, I have not met any good DBAs.



  • @galgorah said:

    @snoofle said:

    @All:

    My boss is afraid of conflict with anyone because his boss is nuts and will fire anyone who makes waves (and can't back it up). As a general statement, I tend not to run my mouth in the office unless I'm certain I can back it up.

    I generally write my SQL to get my point across and then ask someone who is well versed in SQL to make it better (databases really aren't my strong suit). In this case, our DBAs are idiots, but they're militant that things be done their way, and developers have no say. If you argue, they complain to their boss' boss who complains to my boss' boss who then targets you. As such, I just sigh and bill for the time. And post it here.

    As for leaving, I will, at some point, get bored and move on. But I've learned over the years that every place you go has it's share of WTF, so leaving won't necessarily make things better for me. For now, I get to come and go as I please, and that's worth a lot to me.

     

    Unfortunately its a common occurance that DBAs blame devs and devs blame DBAs.  DBAs and Devs should be good friends working together to solve issues. It sounds like your dbas are very junior based on their idea of way over normalizing. 

     From all your past stories it seems like politics rule your workplace. For that you have my condolences.

     

    I've never had an "official" DBA. Either it was every-dev-for-himself (although I would correct really egregious problems in my coworkers database usage) or I was the unofficial DBA. I know a pretty good amount about MySQL and Postgres, but I'm sure there's a lot I could learn if I was in the role of "official DBA". However, what I do works well, so I'm happy with it.



  • @Sutherlands said:

    @galgorah said:

    @TheRider said:
    Ahhh! Good times! I would still marry him anytime... :-)
    This is the definition of a good DBA. 
    I must say then, I have not met any good DBAs.

    They are out there.  Keep in mind too that sometimes a DBAs hands are tied by policy.  Combine that with the fact that if something happens to the data, the DBA takes the blame. A DBA has to balance securing (from malicious users, disasters, etc) the data with providing that data as efficiently as possible.  Thats why a DBA is paranoid. I like to say a good DBA is your paranoid friend! 

     



  • @morbiuswilters said:

    I've never had an "official" DBA. Either it was every-dev-for-himself (although I would correct really egregious problems in my coworkers database usage) or I was the unofficial DBA. I know a pretty good amount about MySQL and Postgres, but I'm sure there's a lot I could learn if I was in the role of "official DBA". However, what I do works well, so I'm happy with it.
    This is how most DBAs are born.  Congrats your an accidental DBA.  Now all you have to do is climb up out of the afterbirth.

     



  • @galgorah said:

    @Sutherlands said:

    @galgorah said:

    @TheRider said:
    Ahhh! Good times! I would still marry him anytime... :-)
    This is the definition of a good DBA. 
    I must say then, I have not met any good DBAs.

    They are out there.
    Given that I'm married, I'm pretty sure there are no DBAs that i would marry anytime.  Particularly "him"s.


  • @galgorah said:

    Now all you have to do is climb up out of the afterbirth.
     

    I believe it's customary for the mother to consume that material.



  • @dhromed said:

    @galgorah said:

    Now all you have to do is climb up out of the afterbirth.
     

    I believe it's customary for the mother to consume that material.

    I'm not sure Morb's manager would too keen on the idea.

     



  • On my current program there are no official DBAs unfortunately.  On my previous two programs we had a team of DBAs, and the development team had a good relationship with them and we worked well with each other.  The leader of the DBA team was this older Korean lady who reminded me a little of Yoda.  English was a second language for her so her English was broken at times, and you would commonly find her sitting Indian style in her chair while sipping a hot glass of tea.  When it came to databases she knew her stuff, was very reasonable and was willing to pass on her sage advice.  The other relationship I find interesting is the Developer - Tester relationship.  On one of my programs any time a developer becomes a tester our favorite joke was saying that they went to the Dark Side.



  • @Anketam said:

    The other relationship I find interesting is the Developer - Tester relationship.  On one of my programs any time a developer becomes a tester our favorite joke was saying that they went to the Dark Side.

    My experience(s): relationships between both is often shaped by the experience of the tester and the devs' perception of the testers' role - and I believe greatly aided by testers being former devs.

    It's an interesting dichotomy: a coder tends to have a constructive mentality, where a tester exhibits a destructive one. If not carefully managed, testers can be viewed as little more smug, obstructive pedantic dickweeds on a power-trip; in synergistic environments, they're viewed as valuable quality assurance staff that have an eye for detail for fault-attacking, communicating not only reported incidents but using their dev background to suggest workarounds/solutions. In the latter case, testers are usually perceived by current developers as mentors who greatly aid learning and growth - said devs perhaps "graduating" to become testers later on in life.

    Some of the more successful working relationships are fostered froma culture that actually encourage low levels of competition between devs and testers. It's not quite a "them and us" battlefield, more a case of the devs trying to build something "unbreakable" by the testers, but the devs also understanding that if it's released broken, it's the testers that cop it.

    A strange love-hate relationship. I've seen it work brilliantly in some places and terribly badly in others. There seems to be no middle ground.

    Discuss.



  • @Cassidy said:

    Discuss.

    It looks like I am going to be a "dev-t", as it is called. That means I am a developer focusing on building testing tools and frameworks for continuous integration, unit and integration tests. The intention is to exhibit as many software weaknesses as can be detected by automated tests. So that the formal testers, which are actually just manual testers clicking around on the UI, will have a less difficult job. I am actually looking forward to this because I have been doing lots of JUnit tests on unit/integration/simulation test levels (where the latter means that systems external to the software under test are being simulated or emulated instead of actually available due to cost issues) and I think I can be coaching the "real" devs a lot by doing this.



  • And would be responsible for testing your frameworks to ensure they performed full and rigorous testing...? 



  • @snoofle said:

    The DBAs created 50-ish temp arrays (minus the type field ), spun through the argument list, and with a huge if-else if statement put common types into the subordinate bucket-arrays, and then forall'd each bucket into the db.

    So you have 50 one row tables?  Can someone explain how this is an improvement over no database at all?  (Other than the fact that it lets the DBAs continue getting a paycheck.)  I mean, I'd think it would require as much configuration to look at all of those different tables as it would to just configure that stuff in a flat file.  (Not an .ini file, but a unix-style config file with unicode (UTF-8, UTF-16, and UTF-32) support and support for a per user override file for any configuration items that may be customizable per user, and so on and so forth such that Blakey's complaint about unix config files suffering the same issues as Window's standardized .ini files is completely unjustified.  Yes, there are responses to every point of that guy's complaints, but I'm not going into them here.)

    Yes, I'm aware of 'DUAL'.  I haven't, however, figured out any use for DUAL that does not belong on this site.



  • @TheRider said:

    It looks like I am going to be a "dev-t",

    Congratulations

    @TheRider said:

    The intention is to exhibit as many software weaknesses as can be detected by automated tests.

    Awesome.  So you get to classify the real attitude of your company.  If they're a decent company and you're competent, you'll be perceived as someone who helps to bolster the reputation of the company, bringing in additional revenue by enabling the company to make a highly reliable product, while reducing cycle time.

    On the other hand, if the company's overly penny-pinching, you'll be perceived as the guy who enabled them to cut the manual testing group.  But the rest of the company will mostly appreciate you, until you're downsized because management realizes you've automated your job (not comprehending that you're continually augmenting the testing to look for additional bugs that have been discovered.)

    And, of course, if the company deserves to be one of this site's regular features, they'll see you as an obstacle to progress, because you find too many bugs.  As more tests are automated, this will get worse, because you'll be looking for more bugs, and they won't be interested in fixing them, just working around your obstacle.  While fixing the bugs *would* be a great way around that obstacle, that wouldn't enter the mind of the WTF developer.  Instead, they create convoluted constructs to bypass your checks, creating additional opportunities for bugs, while leaving the underlying issue there.



  • @morbiuswilters said:

    ...but I'm sure there's a lot I could learn if I was in the role of "official DBA". However, what I do works well, so I'm happy with it.

    Not picking on Morbs, or even on this specific topic...but If one knows that "there's alot" they could learn, how can they make an intelligent decision that something "works well"? Is it not possible that it is "working really poorly" but in some way that they ar completely unaware of?

    In 2004 I worked with one client on some large applications that were very heavy database driven. They "did everything right". Full testing environment with machines slightly slower than the production machines, good representational data that was significantly larger than would be in production, more simultanious users than should ever be seen.  Performance was nearly an order of magnitude better than the requirements. Server utilization was well below thresholds (peaking at about 25% on the DB box). Things were moved into production, and everything was happy for about 6 months....

    Then, based on actual metrics, it was decided to consolidate some production servers. On paper, everything looked great. Once deployed (fortunately into the test environment), performance was horrible (a crawl would be kind). Not one person understood why.

    Without giving away the solution details, what ended up solving the problem was slowing down a number of the operations so that they were less efficient in terms of time and memory utiization....



  • @TheCPUWizard said:

    Not picking on Morbs, or even on this specific topic...but If one knows that "there's a lot" they could learn, how can they make an intelligent decision that something "works well"? Is it not possible that it is "working really poorly" but in some way that they ar completely unaware of?

    I think this is dunning-kruger in part. Most decisions are made "to the best of my knowledge" so the accuracy and quality of that decision is related to the knowledge levels, skillsets and experience of that individual.

    If the decision-maker is of low competancy and they're aware of it then they really ought to highlight the possible low quality of their decisions. If they're relied upon to make regular decisions, they must put themselves in a stronger position - form a business case for additional training, etc to take ownership of that competancy and provide more informed decisions when the business demands it.

    Most costly disasters occur when the decision-maker is unskilled/inept/blissfully ignorant and yet is in denial of their limitations - and may often attempt to shift blame away from their own accountability. Or when the business has poor capability in that area and relies upon the most knowledgable internal person for decisions, rather than pay for higher-quality expertise, often external (contractors, consultants). IME, a business that skills up internal staff to a fair competancy level for business-as-usual then seeks external expertise on an adhoc basis tends to be the most cost-effective at what they do, but that requires business leaders to properly understand (and accept) the organisation's capabilities and limitations, and know where that line is drawn.



  • @Cassidy said:

    Most costly disasters occur when the decision-maker is unskilled/inept/blissfully ignorant and yet is in denial of their limitations - and may often attempt to shift blame away from their own accountability. Or when the business has poor capability in that area and relies upon the most knowledgable internal person for decisions, rather than pay for higher-quality expertise, often external (contractors, consultants). IME, a business that skills up internal staff to a fair competancy level for business-as-usual then seeks external expertise on an adhoc basis tends to be the most cost-effective at what they do, but that requires business leaders to properly understand (and accept) the organisation's capabilities and limitations, and know where that line is drawn.

    In my experience, when a business has really poor capability in a particular area (or even just the upper management for the business), and they seek external expertise to cover for that lack, it's still a dice roll whether they wind up better off or worse off, because usually the people that select the contractor or consultant do not have a sound method for choosing the contractor or consultant.  They can't use their own knowledge of the area - that was already determined to be poor in the beginning of this paragraph.  If they had decent analytical skill, they could look at the track records of the companies that have used the various alternatives - however, the dodgy consulting firms usually don't boast of their failures, and even the worst outfits get lucky sometimes and get a customer who succeeds in spite of their help.

    But, of course, there's also some really phenomenal disasters when the decision maker is highly immoral.  I'm not sure what percentage of financial disasters fall in this bucket, but I'm fairly certain it's higher than the portion that officially get caught.  I've heard of at least one instance where the company thus scammed decided their stock price would be best served by simply tossing the malefactor to the curb than pressing charges.  Given the way the stock market and fiduciary duties work, I suspect that happens more often than not.



  • @Cassidy said:

    @TheCPUWizard said:

    Not picking on Morbs, or even on this specific topic...but If one knows that "there's a lot" they could learn, how can they make an intelligent decision that something "works well"? Is it not possible that it is "working really poorly" but in some way that they ar completely unaware of?

    I think this is dunning-kruger in part. Most decisions are made "to the best of my knowledge" so the accuracy and quality of that decision is related to the knowledge levels, skillsets and experience of that individual.

    If the decision-maker is of low competancy and they're aware of it then they really ought to highlight the possible low quality of their decisions. If they're relied upon to make regular decisions, they must put themselves in a stronger position - form a business case for additional training, etc to take ownership of that competancy and provide more informed decisions when the business demands it.

    Most costly disasters occur when the decision-maker is unskilled/inept/blissfully ignorant and yet is in denial of their limitations - and may often attempt to shift blame away from their own accountability. Or when the business has poor capability in that area and relies upon the most knowledgable internal person for decisions, rather than pay for higher-quality expertise, often external (contractors, consultants). IME, a business that skills up internal staff to a fair competancy level for business-as-usual then seeks external expertise on an adhoc basis tends to be the most cost-effective at what they do, but that requires business leaders to properly understand (and accept) the organisation's capabilities and limitations, and know where that line is drawn.

    have two

     No disagreement.  The best approach I have seen [based on nearly 40 years of observations] is that a mentor is the best thing that can happen. I currently have two (one techncal, one business), and am mentoring four (my upper limit) ranging from young students to a fairly senior (10+ years) developer. I find I often learn as much or more from mentoring as from being mentored [though I learn quite a bit from them].

    It really minimizes the "I don't know what I don't know" problem.



  • @TheCPUWizard said:

    ... The best approach I have seen [based on nearly 40 years of observations] is that a mentor is the best thing that can happen. I currently have two (one techncal, one business), and am mentoring four (my upper limit) ranging from young students to a fairly senior (10+ years) developer. I find I often learn as much or more from mentoring as from being mentored [though I learn quite a bit from them].

    It really minimizes the "I don't know what I don't know" problem.

    Mentors are an invaluable asset.  I went many years without one. However thankfully the SQL community is probably one of the best out there.  It's really easy to get advice from someone who specializes in a certain area.  #SQLHelp on twitter, SQLSaturday, blogs, etc are all amazing resources. User groups are probably the most beneficial however. So even if you don't have a mentor, you can still engage and learn from others who have "been there before" by joining a user group.   

     


Log in to reply