Home Forums SQLServerCentral.com Editorials Database Development Made Easy? RE: Database Development Made Easy?

  • August 30, 2017 at 9:28 am

    #1957488

    Sean Redmond - Wednesday, August 30, 2017 2:34 AM

    Obligatory rant from me:
    Database development *is* easy. Developing databases well is not. You have to know what you're doing and this takes time. You have to apply yourself to learning about it. You have to care that you are doing a good job, rather than simply care about getting the job done.
    I give, as an example, the last database that I received from our developers: all of the string fields were nvarchar(max). All of the numeric fields were int, even the primary key for the languages table (which will hold 4 entries). I am, at least, thankful that it had foreign keys. The database won't be big, I was told, it doesn't matter.

    <RANT>
    This is my life right now.
    I am looking over the database design (including indexing, keys, stored procedures, triggers, functions, views and general table design) for some projects with 'issues' and the one constant that I see is that the developer who built this house of cards took zero time to plan the database structure and ALWAYS went for what was fastest and easiest to build.  

    Most of the tables have no foreign key constraints.
    Indexing?
    Data integrity is not even a concept to most of the dev's.
    Second normal form is violated with abandon.
    Stored procedures are reused without thought as to if the procedure is optimized for the use.  Example: there is one generic 'search' stored procedure that allows many different items to search on (SSN, last name, application ID, date, etc), but is written in such a way that for every 'empty' search parameter, a full table scan is preformed.  
    Data validation. We will add that 'later', which we all know means never.  
    I could go on for hours.

    Most of the dev's hate hearing from me because all of my suggestions require them to 'do more work' and 'take more time'.

    ------

    I read through the linked MS blog about SSDT/VS and was appalled with the insane number of steps and complexity to do something that should be so simple.
    Guess I am getting old, but IMHO the over complicated, GUI driven insanity is strangling the dev's that I work with.  
    Their job keeps getting harder.  Not because of the language, but because of the 'frameworks', 'tools' and 'IDE's' that they are required to use.  

    I am glad that I read this article as it helped me understand some of the ignorance that I am seeing from dev's.
    We have a recurring problem where a dev will try and promote their code to another environment and they just assume that whatever database changes (structural or data) will automagically be promoted.  They look at me like I have three heads when I tell them that no, they have to specify exactly what needs to be promoted (as is clearly spelled out during their orientation and in other documentation they have access to).  Many of the dev's can't understand why VS doesn't do everything for them (including thinking).
    </RANT>