February 6, 2014 at 9:29 pm
Comments posted to this topic are about the item Five Rules For Successful Conversations With Developers
Senior DBA - Gateway Ticketing Systems
Co-Founder - Do It Simply Software
February 7, 2014 at 6:06 am
Very nice article. I was especially pleased to see the mention of Entity Framework. I'm not a full-fledged DBA. I refer to myself as a database developer, handling both ends, building my applications from the ground (database) up and doing my best to follow best practices on both ends, including security. I have never understood how Microsoft and others can push tools (and samples) like Entity Framework (which I don't use) that depend on full table access for users. Where is the concern for security?
February 7, 2014 at 6:21 am
The entire article could have more accurately been written in a single sentence:
"Assume developers literally are smarter then you otherwise they would have settled for being a mere DBA" ;<)
Sorry guys (and ladies) could not resist. And Joshua, really nice article and that is not joking, thanks.
February 7, 2014 at 8:26 am
Good article. I think it's important to note, though, that the word "developer" shouldn't necessarily mean "software developer that doesn't understand good RDBMS design/development practices and/or doesn't care to learn". I have the word "developer" in my job title, but it's preceded by "Database". 🙂 And while I consider myself to be a "developer" (both database and software), I'm a DBA at heart. I think many others fall into this category. Please use the word "developer" carefully, when in this context.
February 7, 2014 at 10:14 am
As a former software developer, I agree whole-heartedly! I'm giving you five stars on this.
February 7, 2014 at 10:17 am
batesview (2/7/2014)
The entire article could have more accurately been written in a single sentence:"Assume developers literally are smarter then you otherwise they would have settled for being a mere DBA" ;<)
Sorry guys (and ladies) could not resist. And Joshua, really nice article and that is not joking, thanks.
bastes - I cannot tell by what you have said if you really believe that a developer is smarter or not. If it was intended as a joke please disregard. I really hope that you did not mean it when you inferred that developers are bright, creative, and talented, and DBA's are what is left. As one who has been on both sides of the discussion and done both jobs I have seen many brilliant, talented, hardworking professionals in both areas. To denigrate them in this manor is totally unacceptable.
But again you are titled to your opinion, so good luck with that.
M.
Not all gray hairs are Dinosaurs!
February 7, 2014 at 11:17 am
They are not going to care about your law against using ORM tools because of how they cause plan cache bloat; they only care that writing all those stored procedures means many nights of late work if they are going to get their work out the door. And frankly, I think they have every right to be upset if you try and push arbitrary changes on them late in the game, especially if they did the right thing and involved you early on in the process.
"the best is the enemy of the good" - Voltaire
I can appreciate that seems reasonable if your scope of concern is the database; however, as someone who is responsible for delivering entire systems, this line of thinking is troubling. My chief concern is delivering value over the life cycle of the systems we build. In some cases, if not many, the result we are seeking is achievable using software which is not highly tuned in combination with some extra hardware. I'm not advocating sloppy development practices, but the reality, in economies like that found in the US, is that hardware is cheap and people are expensive. Why would I allocate developers to a problem that can be solved by a capital expense? How is the business not better served by assigning a human work that she, barring the awakening of Skynet, is uniquely qualified to perform? It may offend your engineering sensibilities, but my position is that assignment of resources to their best use is the right answer when operating in a commercial setting. After all, keeping the business profitable, not optimal use of the plan cache, is what keeps those paychecks coming to me and the DBAs I work with.
February 7, 2014 at 12:20 pm
Nice, but I think you meant
set @start_of_day = dateadd(day,datediff(day,0,@date),0);
rather than
set @start_of_day = dateadd(day,datediff('day',0,@date),0);
or am I missing something?
February 7, 2014 at 12:26 pm
I strongly agree on the best practices documentation and script repository for the best way to educate any professional (software/database) developer.
From my perspective the example used (first date) is very basic, so any developer giving that solution should be a junior one, whose code must be reviewed as a good practice in any development process but ok “shit happens”.
Now entering the epic battle DBA vs Developers, ideally any high end systems architect will start the design from the systems component down, leaving the database layer ultimately as a kind of persistent layer that should not have any “business rule” built in, again ideally!
In the DBA vs Developers battleground the “write an stored procedure to accomplish that business” process is attacked as if we write (DBA) the SP any other change that is needed can be done without the need of an application development (translated as we can modify it faster in production) sadly true, but terrible wrong (it depends).
Nhibernate or related technologies have problems related to the same problems that DBAs blame developers (poorly sql sentence), but eventually this technologies will generate the desired sql and will accomplish the purpose of abstraction from the database layer.
Most of the time I fight on both sides (DBA/Developers), there is no golden rule and at the moment no ideal solution. I do love database development( not a DBA hater) , I really like getting inside tips from the DBA when the project has one, and try to accomplish by myself any DB part (stored procedures, DB design etc) but still believe the development world is more fun and problematic.
😀
February 7, 2014 at 12:44 pm
This works too:
set @start_of_day = cast(cast(@date as date) as datetime)
February 7, 2014 at 4:23 pm
john 69568 (2/7/2014)
Nice, but I think you meantset @start_of_day = dateadd(day,datediff(day,0,@date),0);
rather than
set @start_of_day = dateadd(day,datediff('day',0,@date),0);
or am I missing something?
You might test your "corrections" before you post...
.. your "correction" will give you an 'invalid parameter' error...
February 7, 2014 at 9:13 pm
Well, the inverse is true for me. Maybe you have a server setting that allows datepart to be quoted? Something other than
DATEDIFF ( datepart , startdate , enddate )
and the examples such as
SELECT DATEDIFF(day, '2005-12-31 23:59:59.9999999' , '2006-01-01 00:00:00.0000000');
at http://technet.microsoft.com/en-us/library/ms189794(v=sql.110).aspx?
February 8, 2014 at 3:03 am
Miles, seriously this did not give you a hint: " ;<) " ?
Sorry if teasing the DBA crowd here offended you, it was not intended that way but instead to provoke a mild chuckle heading into the weekend.
Best of luck to you in future endeavors.
(when you have a spare minute or three if that ever occurs, read up on what are called 'emoticons')
February 9, 2014 at 11:04 am
Where is the DBA function on the IT org chart? Does it have its own box? You can bet Servers and Network do and probably Applications Development. Why does this matter? It is a reflection of how the organization (management) views the DBA function. I submit that it begins and ends with management. If management places the DBA function in some other group (Applications for example) that tells me that SQL Server (or Oracle) is not viewed as an enterprise level resource but as an appendix.
The DBA and the developer who are incapable of saying "I could be mistaken..." are going to have a some tough sledding.
February 9, 2014 at 10:13 pm
Very nice article. I like the points raised. I am in particular agreement with "Be a teacher, not a bully" and to not include the world in communications. Those can be huge in helping to deal with developers or dbas and trying to build a relationship.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply