Do as I say, not as I do

  • Comments posted to this topic are about the item Do as I say, not as I do

  • If you know there are better practices you should follow, then take the few extra moments to implement them. If you don't know of good practices, start compiling a list, asking questions, even post an idea or question in the discussion for this editorial.

    I think it is important to understand why something is a better practice. Can we always distinguish between something that is "best practice" and something which is merely a personal preference?

    If someone asks why a particular thing is standard, then there should always be a well argued reason for it.

    I've seen people impose rules forbidding views, triggers, CTEs and cascades on foreign keys among other things - I have never been given a convincing explanation of why these things shouldn't be used. If you understand how to use these things properly then they are perfectly legitimate. Views in particular are an absolutely fundamental part of an RDMBS and are the relational way of introducing reuse.

    I try to avoid using temporary tables, if you ask me why, I hope I would be able to give you a convincing argument why. But notice I say "avoid" not "never".

    • This reply was modified 3 years, 4 months ago by  will 58232.
  • Microsoft: "Don't write code that requires sa"

    Also Microsoft: "To do the following in Dynamics you'll need sa"

  • Aye, but if you can manage to find anything in Dynamics or Sharepoint that could be considered good practice, I do believe there's a prize on offer

    I'm a DBA.
    I'm not paid to solve problems. I'm paid to prevent them.

  • will 58232 wrote:

    If you know there are better practices you should follow, then take the few extra moments to implement them. If you don't know of good practices, start compiling a list, asking questions, even post an idea or question in the discussion for this editorial.

    I think it is important to understand why something is a better practice. Can we always distinguish between something that is "best practice" and something which is merely a personal preference?

    If someone asks why a particular thing is standard, then there should always be a well argued reason for it.

    I've seen people impose rules forbidding views, triggers, CTEs and cascades on foreign keys among other things - I have never been given a convincing explanation of why these things shouldn't be used. If you understand how to use these things properly then they are perfectly legitimate. Views in particular are an absolutely fundamental part of an RDMBS and are the relational way of introducing reuse.

    I try to avoid using temporary tables, if you ask me why, I hope I would be able to give you a convincing argument why. But notice I say "avoid" not "never".

    A few years back I became very interested in good software design patterns. I hadn't learned any when I was in college, although my major was Mathematics, not computer science. 😉 Regardless, I don't think people who get their Bachelor's in CS are taught software design patterns.

    So, I looked for some courses to help me learn good design patterns. I found an excellent one on Pluralsight, named Design Patterns Library. That is the longest course I've seen on Pluralsight. There are a lot of good software design patterns there to use.

    I don't know if there's a similar resource for DBAs, or writing good SQL (T-SQL, PL-SQL, whatever). I hope there is.

    Rod

  • Still finding ntext datatypes in sql server reporting services 2019 🙁

  • I think we could do more to promote the advantages of using a SQL-DBMS.

    I can understand that some developers might have developed an aversion because of the behaviour of some of the "old school" DBAs who regarded developers as someone out to destroy and corrupt their beautiful database, or at least bring performance to its knees with some ill written query.

    Since I started working with RDBMSs back in the 1980s, it seems like every year something comes along that is "going to make the relational DBMS obsolete". That this hasn't happened isn't because people are too conservative, it is because the relational model is a brilliant idea, that is still ahead of its time and has yet to realise its full potential.

    I think we need to try and be more effective at bringing these advantages across.

Viewing 7 posts - 1 through 6 (of 6 total)

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