What should developers understand about administration?

  • I'm teaching a class on database basics to a group of college students whose course program is designed to get them jobs as developers of some type. So far my class has been about the basics of normalization, primary keys and foreign keys, etc; table and relationship design topics, mainly to give budding app developers a sense of the "what" in a database. There has been very little "how" and "why" of the RDBMS itself.

    What would the DBAs out there like to see new hire developers have a basic idea about when it comes to what you need them to take into consideration in the larger RDBMS outside of their app's tables? Think of the last design stage meeting where there was some new kid who had an idea for a table but didn't get some part of what you were trying to explain about your RDBMS's requirements or processes.

    I plan to cover at least the importance of backups and difference between full and incremental; Any others administrative duty things? Keep in mind these kids are highly unlikely to be hired as junior DBA's - they'll end up as developers of some type who will need to interact with your RDBMS. Also keep in mind that I know enough about DBA duties to either cause a lot of trouble for or help out the real DBA, depending on your point of view (I've been accused of both in other threads); mainly I develop ETL when I'm not at this teaching gig.

    Thanks for your suggestions

  • Set based queries. Stay away from cursors! With that, they need to think differently when accessing data, they need to think in sets, not rows.

  • Security, security, security and just for completeness, security.

    They need to understand and understand the reasons for the Principle of Least Privilege.

    They need to understand injection and how to prevent it (hint: not by filtering for certain words)

    They need to understand why an admin will yell at them if they insist that their app needs SA permissions.

    Also, to add another topic, basic database design. Enough to understand that it's a complex area and not something that gets a 5 min look at at the beginning of the project and never again.

    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

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Use any "Best Practice..." white paper. Brad McGehee (RedGate) has excellent free e-book (SQL Server DBA Best Practices) that shows what developer should know: no SELECT DISTINCT, avoid CURSOR, know how to use profiler, what is cost-based optimization, how clustered/non-clustered index affect performance, store procedures vs. dynamic SQL,

    Alex Prusakov

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply