May 15, 2017 at 7:10 am
Jeff Moden - Sunday, May 14, 2017 12:52 PMMatt Miller (4) - Sunday, May 14, 2017 11:52 AMJeff Moden - Sunday, May 14, 2017 8:49 AMroger.plowman - Friday, May 12, 2017 12:28 PMJeff Moden - Wednesday, May 10, 2017 1:07 PMDavid Burrows - Tuesday, April 18, 2017 2:15 AMJeff Moden - Friday, April 14, 2017 7:50 PMAnd, my personal opinion, Developers should NOT be designing tables or indexes.With my DBA hat on I tell the developer (me) that.
And with my developer hat on I just laugh at the DBA.
😛Agreed on both but, with your developer hat on, would you create an NVARCHAR(1) column to store a single digit or would you create a NUMERIC(18,0) to store a value of something between 0 and 255 or would you create all character columns as NVARCHAR(MAX) or even NVARCHAR(4000).
Once you've been a DBA, you can't actually ever forget just because you need to wear your developer hat. 😉
Not to be picky, but don't all of your examples fall in the developer arena anyway? After all, correct variable typing is kind of programming 101...
Actually, I stand corrected... And, no... you're not being picky at all. I seems that it doesn't matter what people's titles are, a lot of them miss (or flat out don't know) such important basics and that certainly includes people that tout the label "DBA" after their name.
I'm not sure I fully agree. A "pure" developer wouldn't be discussing data types using the DB terminology for it. If there's an expectation that the devs stay out of the table definition business then there's also expectations that they'd be using terminology based on the language they are developing in such as "string" or "stream" or "array of character". Should they be involved in implementing constraints appropriate to the object they're using? Absolutely, but they would define their own using their own terminology, since data types are the business of the data modeler (which may also be wearing the DBA hat as well.)
This unfortunately involves having to translate "optional" flags into nullable or variable length data types on the data side.
I'm thinking that's a major part of the problem. They don't know what they don't know and, yet, their managers (who also don't know what they don't know) think it's ok if the Developer uses tools that create columns as NUMERIC(18,0) for all integers and NVARCHAR(128) or (256) for all character based columns as a default.
I worked "with" a Developer that claimed to be an "expert" and he did this a whole lot. When I asked him why he didn't use correct sizing, he misused Knuth's parable about pre-optimization being the root of all evil. When I asked him when he intended to do the correct sizing and data-typing, his answer was that there was no need since the database was just a place to store data. He was also the first one to claim that the server was slow and that's why his code on his tables was slow. 😉
In other words, Developers (front-end or otherwise) are frequently used as data modelers and, while some are very good at it, I find that's the exception rather than the rule. Unfortunately, I've found the same to be true for many Database Developers and, so called, Data Modelers and DBAs.
A recent example of something that I had to correct was where a fairly good Developer created columns for NPA and NXX (3 digit area code and 3 digit exchange) using NUMERIC(3,0) on what will become a large table. For those that miss the nuance here, the NUMERIC data-type takes 5 bytes for anything from 1 to 9 digits of precision. A SMALLINT easily handles 3 digit numbers and only takes 2 bytes, which is less than half the size both in the Clustered Index and in every Non Clustered Index on either or both of those two columns.
With that, I'll have to disagree with your disagreement and suggest that front-end Developers can no longer be just "pure" Developers anymore than "pure" Systems DBAs can any longer get along without knowing how to use T-SQL.. 😉
Maybe it's just because I've always been a lone wolf developer, but I haven't generally had the "luxury" of being able to foist the DB development role onto someone else. In my view the correct data typing (and constraints and auditing and entity design) is all part of the *application*.
I've also been in this since the days when 8K was considered adequate for computer memory so I got into the habit of being miserly with memory/disk resources. Amazing how what is old is suddenly new again, isn't it?
Considering the DB to be "just a place to store data" is so brain-dead I can't even get my head around it. That sounds like a PHB, not a programmer! In the app I'm currently developing I'm at 500k lines of code, almost evenly split between SQL Server and VB.Net. So wouldn't it appear both are equally necessary?
I'm reminded of this quote from Charles Babbage:
"On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
I mean, come on! Any code directly touching the data is going to have to be either T/SQL or CLR. Anything dealing with the data itself is going to be done in SQL Server, and since that's where ALL the data is, surely it stands to reason that DB best practices will profoundly impact performance?
May 15, 2017 at 7:35 am
roger.plowman - Monday, May 15, 2017 7:10 AMMaybe it's just because I've always been a lone wolf developer, but I haven't generally had the "luxury" of being able to foist the DB development role onto someone else. In my view the correct data typing (and constraints and auditing and entity design) is all part of the *application*.
I've also been in this since the days when 8K was considered adequate for computer memory so I got into the habit of being miserly with memory/disk resources. Amazing how what is old is suddenly new again, isn't it?
Considering the DB to be "just a place to store data" is so brain-dead I can't even get my head around it. That sounds like a PHB, not a programmer! In the app I'm currently developing I'm at 500k lines of code, almost evenly split between SQL Server and VB.Net. So wouldn't it appear both are equally necessary?
I'm reminded of this quote from Charles Babbage:
"On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
I mean, come on! Any code directly touching the data is going to have to be either T/SQL or CLR. Anything dealing with the data itself is going to be done in SQL Server, and since that's where ALL the data is, surely it stands to reason that DB best practices will profoundly impact performance?
Heh... right there with you. I was the big-gun on the block because I did have 8K and a cassette interface to save stuff on. Most everyone else had 4K and they had to leave their machines on or lose what they had.
And I love the Charles Babbage quote. Been a big fan of it for many years because it shows that not much has really changed. 😉 I guess that's a big part of why the idea of AI scares me so.
In the case of SQL Server and T-SQL, I've been told over and over that I shouldn't be using SQL Server for ETL and a wealth of other data intensive programming. My return question is "Why not? That's where the data lives". The normal retort is "Just because you can do something in SQL Server, doesn't mean you should". My retort is "Why not? That's where the data lives. Why do you think so much needs to be taken out of SQL Server"? That normally takes the person I'm talking to over the edge and they blurt out "Because SQL Server is not the center of the universe"! At that point, I end the conversation with "Cool... let's turn it off and find out". 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
May 15, 2017 at 7:57 am
Jeff Moden - Monday, May 15, 2017 7:35 AMroger.plowman - Monday, May 15, 2017 7:10 AMMaybe it's just because I've always been a lone wolf developer, but I haven't generally had the "luxury" of being able to foist the DB development role onto someone else. In my view the correct data typing (and constraints and auditing and entity design) is all part of the *application*.
I've also been in this since the days when 8K was considered adequate for computer memory so I got into the habit of being miserly with memory/disk resources. Amazing how what is old is suddenly new again, isn't it?
Considering the DB to be "just a place to store data" is so brain-dead I can't even get my head around it. That sounds like a PHB, not a programmer! In the app I'm currently developing I'm at 500k lines of code, almost evenly split between SQL Server and VB.Net. So wouldn't it appear both are equally necessary?
I'm reminded of this quote from Charles Babbage:
"On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
I mean, come on! Any code directly touching the data is going to have to be either T/SQL or CLR. Anything dealing with the data itself is going to be done in SQL Server, and since that's where ALL the data is, surely it stands to reason that DB best practices will profoundly impact performance?
Heh... right there with you. I was the big-gun on the block because I did have 8K and a cassette interface to save stuff on. Most everyone else had 4K and they had to leave their machines on or lose what they had.
And I love the Charles Babbage quote. Been a big fan of it for many years because it shows that not much has really changed. 😉 I guess that's a big part of why the idea of AI scares me so.
In the case of SQL Server and T-SQL, I've been told over and over that I shouldn't be using SQL Server for ETL and a wealth of other data intensive programming. My return question is "Why not? That's where the data lives". The normal retort is "Just because you can do something in SQL Server, doesn't mean you should". My retort is "Why not? That's where the data lives. Why do you think so much needs to be taken out of SQL Server"? That normally takes the person I'm talking to over the edge and they blurt out "Because SQL Server is not the center of the universe"! At that point, I end the conversation with "Cool... let's turn it off and find out". 😉
Heh.
I don't know that I agree about ETL being best handled by SQL Server. The transport of pre-sanitized data into staging tables, yes, absolutely, it's capable of FTL speeds doing that, but T/SQL is not a language geared for the intensive string manipulation like in say, validating CSV data files.
Don't get me wrong, I wish it was. T/SQL is *painfully* antiquated. It has been optimized for performance of one task, leaving everything else in the dust. Any looping, any in-memory manipulation--well, it's been optimized for performance of fetching and carrying, not programming niceties like code reuse and programming performance of the interpreter.
Frankly it reminds me of 1960s era code (and compares *badly* to it...).
Horses for courses. Let T/SQL deal with fetching, carrying and storing. Let application code deal with data manipulation that T/SQL doesn't do well.
But damn it developers, learn what constraints and indexes are for! (laughing)
May 15, 2017 at 11:38 am
Jeff Moden - Sunday, May 14, 2017 12:52 PMA recent example of something that I had to correct was where a fairly good Developer created columns for NPA and NXX (3 digit area code and 3 digit exchange) using NUMERIC(3,0) on what will become a large table. For those that miss the nuance here, the NUMERIC data-type takes 5 bytes for anything from 1 to 9 digits of precision. A SMALLINT easily handles 3 digit numbers and only takes 2 bytes, which is less than half the size both in the Clustered Index and in every Non Clustered Index on either or both of those two columns.
Beware the wrath of our favorite curmudgeon. He's going to tell you that you shouldn't be storing phone numbers as numbers at all, because you're not going to be doing math on them.
May 15, 2017 at 1:56 pm
I have no problem dealing with developers, I just wish they would "up their game".
Last week, a piece of code that loops(!) through a bunch of records to insert them into a table timed out out at the UI level.
What did the dev's do? They logged into the database server, and starting clicking around looking for anything labeled "logs". They removed the permissions on the data and log folders for the SQL Service account. Thankfully, this was not production. I have no idea why the first place they looked about a timeout issue in their code was the database server "logs".
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
May 15, 2017 at 8:48 pm
Jeff Moden - Sunday, May 14, 2017 12:52 PMI'm thinking that's a major part of the problem. They don't know what they don't know and, yet, their managers (who also don't know what they don't know) think it's ok if the Developer uses tools that create columns as NUMERIC(18,0) for all integers and NVARCHAR(128) or (256) for all character based columns as a default.
I worked "with" a Developer that claimed to be an "expert" and he did this a whole lot. When I asked him why he didn't use correct sizing, he misused Knuth's parable about pre-optimization being the root of all evil. When I asked him when he intended to do the correct sizing and data-typing, his answer was that there was no need since the database was just a place to store data. He was also the first one to claim that the server was slow and that's why his code on his tables was slow. 😉
In other words, Developers (front-end or otherwise) are frequently used as data modelers and, while some are very good at it, I find that's the exception rather than the rule. Unfortunately, I've found the same to be true for many Database Developers and, so called, Data Modelers and DBAs.
A recent example of something that I had to correct was where a fairly good Developer created columns for NPA and NXX (3 digit area code and 3 digit exchange) using NUMERIC(3,0) on what will become a large table. For those that miss the nuance here, the NUMERIC data-type takes 5 bytes for anything from 1 to 9 digits of precision. A SMALLINT easily handles 3 digit numbers and only takes 2 bytes, which is less than half the size both in the Clustered Index and in every Non Clustered Index on either or both of those two columns.
With that, I'll have to disagree with your disagreement and suggest that front-end Developers can no longer be just "pure" Developers anymore than "pure" Systems DBAs can any longer get along without knowing how to use T-SQL.. 😉
I'm reminded of this quote from Charles Babbage:
"On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
Jeff, I couldn't agree more. It is a part of the problem. Just like in any environment, people need to know the environment they're in and work efficiently.
And Roger, I absolutely love that quote. I must agree - the confusion of ideas must be immense. Yet, in response to that, I work with some people who have asked something very close. They have incorrect data and want correct analysis. It's actually happened. :w00t:
March 16, 2022 at 9:52 am
Programmers aren't stupid. Some programmers don't know what they're doing and don't care that they write bad code. They think they know everything and aren't willing to change. Then they don't care about their work and make your life harder. There are many ways to deal with programmers. Here are some tips to help you deal with these people. o Don't expect perfection from them.
April 18, 2022 at 2:02 am
This was removed by the editor as SPAM
June 23, 2022 at 9:21 am
This reply has been reported for inappropriate content.
My thought process is that you want to have the so-called serious "come to Jesus" meeting with the supervisors to lay out principles and a technique for upholding them. What's more, my conviction is, Developers ought not to be planning tables or files. That likewise implies that the directors need to figure out their timetable assumptions.
Thanks
luxury office furniture in Dubai
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply