Featured Article(s)
Things Your Mother Never Mentioned About Setting Up An Oracle Database – Steps 1 and 2
After creating an Oracle database a number of tasks remain before really using the database. This article is the first in a series of articles that desribe these tasks. This article describes how to set up the environment.
New SQL Server Show Posted
SelectViews: SQL Server 2008 Upgrade Experiences, Departmental Databases, What is Growing Your Database? Uptime and Downtime Planning, Upcoming Events, xp_cmdshell Tips and a Lot More.
[Watch Show]
Embedded DBAs
On Friday we had an issue with the newsletter, so many of you (most? all?) did not receive the thought for the day. I thought I’d include it here.
You’ve Heard of Embedded Reporters?
Ralph suggests embedded developers (and I’d extend that to embedded data analysts):
"I go far enough back in my career to be able to remember the "Priesthood of the Blue and Grey Boxes" . . . i.e. he days of the big IBM Mainframes that sat in "goldfish bowls" that were highly air conditioned (with the humidity kept at 50%). I can also remember the complexity of the applications and the "nightly job streams" that kept all of the company’s data (albeit, a day behind ;-). More significantly, I can remember the Authority (definitely spelled with the capital "A"!) that the Priests of the Mainframes had over whatever went on in the Mainframe.
Early on, though, I was one of those who worked in a company whose existence relied upon pulling together the hardware, figuring out how to interface it all, and then creating the software (including the "OS" such as it was). As a result of that, I adopted the mindset of "I am there to provide whatever is needed for the user to have the machine work for them rather than having them work for the machine." (Only later did I learn that there was a big mainframe somewhere keeping our company’s books. 😉 Thus, I have never quite understood those who want to not only separate the IT functions from the Business Users but to also make sure that there is as little contact as possible between the Business Users and the Developers.
IMHO, anyone who would contend that they can interview a few Business Users and then draw up a comprehensive plan for developing a complex business system that the Business Users will never need to change is probably a candidate for the Bone-Head of the Year award. Unless there is good communication and interaction between the Users and the Developers, the Users are never really going to be or stay happy with what the Developers "give" them.
All too often, after having designed a solution to a problem while sitting at my desk. I have only realized how badly I designed the "solution" when I sat at the User’s desk and watched how they were trying to get their work done. That is why there is, IMHO, a need for either an "embedded" developer within departments or a designated liaison between the departments and IT . . . someone who can interpret for both IT and Business. "
Featured White Paper(s)
Structuring the Unstructured: How to Dimensionalize Semi-Structured Business Data
The Business Intelligence industry is paying more and more attention to the ever-growing heap of unstructured and semi-struct… (read more)
EMC Metropolitan Recovery for SQL Server 2005 Reference Architecture
Learn about EMC’s Metropolitan Recovery for SQL Server 2005 solution in this Reference Architecture guide. See how you can us… (read more)