The Virtual Conference Starts Tuesday!
It’s time to register – it’s easy, quick and you even get a DVD to choose and membership here on SSWUG.ORG.
Oh, and the content! 30 sessions, more than 10 speakers, top names with top information and tips – so much information you’ll be really counting on the 45 days of included on-demand time to watch, re-watch and re-watch the sessions. You have nothing to lose (literally – we guarantee the virtual conference!).
> Get more information
> Register
3 days of excellent content – please join us, we’ve pulled all of the content together just for you!
The Changing Role of the Database Architect
Solid database architecture is just as valuable today as ever. Good database design may result in data that is more pure and therefore more useful. That being the case, I believe we may be seeing an increase in the individual with skills reaching out beyond that of SQL and into the applications itself.
Here are some more thoughts from you, our readers.
David:
Our DBA group is now dealing with a group of developers who are starting a large project using MVC Code First. I am very skeptikal about this technology since it is not only a whole new methodolgy but it also throughs the "baby out with the bath-water." Everything DBAs have been taught about normalization, stored procedures, views, and proper indexing is now turned on its head. I am very afraid that we will become a clean-up team after the thing falls on its face. I am also very afraid that the database is going to get blamed for poor performance and somehow it will be our fault.
I guess my biggest concern is that the DBAs will be turned in to developers.
Maurice:
There is effectively a trend toward making database engine not more that CRUD processors. This is not always a great success also. Sometimes processing many rows at one using a single well written query is much faster (x30) than row by row processing.
One of the thing that misses the point about making database development accessible to day-to-day programmer, is the lack of use of newest SQL features like common table expressions and user-defined functions to make not only a fast, but also an easy to understand SQL code. When properly used, CTE document naturally the query (by giving the purpose of the CTE content in the name of the CTE). For function it is trivial to document something by proper naming, but people doesn’t always have this habit for CTE. Analytic functions (row_number + over) complement the toolset of solving easily traditionally hard to resolve SQL problems.
So programmers have the problem of maintaining un-readable queries, and tend to turn toward more “procedural friendly alternatives on client side”, because they don’t know the new stuff could ease their work.
Sometimes this is DBA fault, who don’t adopt / share these new techniques and rely on convoluted correlated sub-queries that even other DBA have problem to read. This is time to stop thinking that way of writing queries was a great time and show how great you are as a SQL coder. This is a dismally abstract and unfriendly way to make SQL code. Now we can write powerful and easy to understand queries easily and it is time to teach it to others.
P.S. One a the latest addition to SQL2012 is to complement the feature set associated to analytic functions accordingly to the latest SQL standard. This is another set of traditionally hard SQL problems that goes away (see the clause over).
Jim:
I have been a DBA for over 26 years on mainframe, Unix, and Windows SQL Server. For the Windows environment, you are probably correct that the combined blend of programmer and OLTP DBA role will soon be passé. What I have seen is a growing divergence in roles to more of a dedicated DBA and dedicated programmer/developer.
There is too broad of scope to be an expert in both of these roles. In fact, some would say there is too broad of scope to be a dedicated DBA with expertise in OLTP and Business Intelligence, especially if there is a mixture of OS platforms (including Azure) in the enterprise. We also sometimes forget that DBAs cannot just be a group of technical gurus. We have to some degree of understanding about the business applications to add real value to the bottom line. In a nutshell, application availability is at risk by a simple production mistake by a DBA whose technical scope is spread too thin.
Thanks for the comments. You can reply by email to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Where does IM and Chatting fit in the professional environment?
In the previous newsletter article, we covered some important uses for email and email etiquette (don’t miss another professional newsletter tip—signup for the free newsletter here). A follow-up client question (regarding the previous newsletter article) was “Do you think Chat and IM is an appropriate substitution for email?” Steve Wynkoop and I did a quick interview segment on this very question. This article expands on those points touched in the interview in more detail.
Featured White Paper(s)
All-At-Once Operations
Written by Itzik Ben-Gan with SolidQ
SQL supports a concept called all-at-onc… (read more)