New Video: SQL Server 2005 Jobs and Tasks
SelectViews special – how to work with SQL Server 2005 jobs, tasks and more. We’ll look at monitoring the job system, seeing what the status is, demo the steps to add a TSQL job (specific demo) and a lot more. This is a different format show – would love to have your feedback!
> Watch the show here
Other Video Programs/Shows available:
[Watch] SQLonCall – Creating Standards for Your SQL Server
[Watch] SelectViews – Accidental DBA Tips II, Security, Data Masking and more
Featured Article(s)
myLittleAdmin for MS SQL 2005 from a Webhosting Perspective
As a host, it’s often difficult to recoup the costs on tools like this since they’re typically "value added" as part of the hosts offerings. Well, consider that opening up your firewall ports would make the server more vulnerable to DDoS , script kiddies, and viruses. Second, many hosted users have no experience with MS SQL, much less the management tools and how to find and install them. Third, external access to a SQL Server costs money in terms of bandwidth. A web-based tool like myLittleAdmin takes all of this out of the equation.
Final Thoughts (For Now?) On Job Titles and Responsibilities
I had a number of people write in about the job titles, hiring new people just for new titles and such. I tend to think we collectively need to step up and learn the new technologies and approaches, but I know people too that simply refuse to come forward into new technologies. Ralph wrote in and had a few other ideas and thoughts that I thought I’d pass along here.
Dan wrote:
[The reason most poorly architected databases exist is because business changes, not because the original creator was a moron.]
Unfortunately, in some cases, the original creator, while perhaps not a moron, was from a different era of computing and was not as familiar with the Normalization Rules as they might have been. Some databases simply need to be redesigned from the ground up, so to speak. However, due to the amount of "legacy code" that has built up around the original database "design", this becomes a rather delicate procedure.
As for:
[Hire one person who knows the business and he will be able to architect and administer the database.]
If the business is car sales and you hire the penultimate car salesman, how does that qualify that car salesman to design and develop databases? The answer is that it doesn’t. If the business is banking, does someone who really knows banking really know how to design a database for banking? I would contend that the answer is, again, "No."
Similarly, given most large databases, the requirements for maintaining their hygienic facets (i.e. back ups, restores, maintenance plans, Security, tuning, etc.) can easily be a full time job for someone who is extremely detail oriented. Yet, _someone_ needs to be looking at the requirements for new databases, tables, stored procedures, etc. Swapping someone back and forth between these tasks would seem, to me, to be counter productive unless the databases are relatively small and few in number.
As for having the same acronym being employed for each of the three possible positions (Architect, Analyst, and Administrator), perhaps different terms could be used. For instance, DBM (Database Modeler), DBE (Database Engineer), and DBA (Database Administrator)?
Featured White Paper(s)
Deploying Microsoft® SQL Server in an iSCSI SAN
This Technical Report describes how to deploy SQL Server in an iSCSI SAN with PS Series storage arrays. It provides configura… (read more)
Improving .NET Application Performance and Reliability with Managed Database Connectivity
Your choices about data access can make the difference between project success and project failure. Read this whitepaper and… (read more)