Do a project needs a seperate team for SQL?

  • If you are using Agile as your development methodology, then best practice is to include all the skills you need for a sprint in a single team. If you have dedicated teams for specific skill areas then you are forcing the use of a waterfall approach, and this will really hurt your development velocity and therefoer increase your development costs.

    Most SQL code can be written by anyone in the sprint team. However, you should have site standards about the use (or non-use) of stored procedures, etc - the objective of this is to have a 'contract' of what is required before something can be accepted into UAT and Production. All shops will have subject matter experts, and where a sprint team determines in its sprint planning that it will need extra advice (e.g. for a complex SQL process) then it can schedule time with the required SME.

    Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

  • EdVassie (1/4/2012)


    Most SQL code can be written by anyone in the sprint team.

    Gosh... I've worked in shops that have taken that stance. Unless they generally keep things to simple C.R.U.D., it usually turns out to be a performance disaster down the road (and not very far down the road, at that).

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    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.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Dev (1/3/2012)


    Jeff Moden (1/3/2012)


    MysteryJimbo (1/3/2012)


    Jeff Moden (1/3/2012)


    There's also a matter of timing here. I've found that if you start the database development before you start any of the front end development, you end up with a much more correctly designed database that works well and tends to be much more scalable.

    Very true. At least 5 days head start depending on the upfront requirements already being gathered. In an agile way, the requirements can then be expanded and added to during development based on a good upfront design.

    In some companies I've found the bad practice opposite. Some tables have been directly linked to the fields on a form rather than correctly modelled. If they were on a single form, they went into one table.

    Agreed... a single table for each screen where all integer columns were BIGINT, all character based columns were NVARCHAR(4000) or NVARCHAR(8000), and little, if any, concept of what normalization is (multiple phone numbers and addresses in the Customer table, for example).

    Yup... comma separated or pipe separated columns. And within few days of development / maintenance they will come back to SSC & ask ‘I have CSV columns, please help me in getting in a table’.

    Indirectly, we will sell String Splitter. 😎

    Those are always fun. An OTLT (One True Lookup Table in the form of an EAV) is much more fun! After all, you only need one index for such a thing. 😉

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    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.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 3 posts - 16 through 17 (of 17 total)

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