I often talk with people about building their brands and finding a way to ensure they are a highly desirable employee. One of the ways that I think people can do this is with a technical blog about their career. Having a technical blog allows someone to show off their skills in a particular area. The blog doesn't have to be ground breaking work or extremely innovative solutions to complex problems. While employers need those people, they also need people that do solid work every day on regular problems.
An interview isn't a great way to find good employees. Many of us have had experience with either (or both) sides of the interview table and realize that interviews aren't necessarily that helpful. If we bothered to track the impressions we make of candidates and compare that to the actual work they accomplish over the first year or two, I suspect we'd find that we have no evidence that were making great decisions. The success of employees seems to be a bit hit and miss.
A blog, however, provides the employer with a bit more confidence that a person can handle the job they are hired for. A blog takes time, and across months (or years), it can show quite a bit about a person's knowledge and skills. It allows hiring managers, and co-workers that may interview a person, the ability to perform a bit more due diligence and investigation into someone's skills than an interview provides. It's much more of a representative look at a person than what they say or write on a resume.
I know that it isn't a perfect solution. People plagiarize posts and copy from Books Online and more, but the Internet helps here. Search a few of their paragraphs and you might catch plagiarizers easily. After all, someone that wants to copy posts to avoid work, probably has a few other tricks in their bag to avoid doing other work for you.
Think about starting a blog today and giving potential employers a way to learn more about you.
The DBA Team return in The Girl with the Backup Tattoo. When a crazy DBA tampers with his own backups, even the DBA Team need to call on some extra help to fix the damage. Will they succeed? Read the new article now.
An accidental DBA? Try SQL Monitor
Use the full product free trial to get easy-to-understand insights into SQL Server, and get suggestions on how to solve any problems you find. Begin your free trial.
Free eBook: SQL Server Backup and Restore
With the tools, scripts, and techniques in this free eBook, you will be prepared to respond quickly and efficiently to disaster, whether it's disk failure, database corruption, or accidental data deletion. Download the free eBook.
Marcin Policht reviews security related challenges of Microsoft Azure Software as a Service-based SQL Database, focusing in particular on the SQL Server and database-level firewall access control functionality and methods that can be employed to implement it. More »
I wrote a guide about using Git and GitHub for "Windows people".
This is the guide I wish was available when... More »
Question of the Day
Today's Question (by Steve Jones):
I have created a certificate for the login/user Sales1 as follows:
CREATE CERTIFICATE Sales1Cert
AUTHORIZATION Sales1 WITH SUBJECT = 'Salesperson1 certificate'
I have also created a symmetric key that has been used to encrypt some sales data as follows:
CREATE SYMMETRIC KEY SalesSymKey
WITH ALGORITHM = AES_128
ENCRYPTION BY CERTIFICATE Sales1Cert
I now want to give Sales2 access to decrypt the data encrypted by the SalesSymKey symmetric key, but I don't want them to have access to other keys that are encrypted with the certificate Sales1Cert. What two things should I do?
Think you know the answer? Click here, and find out if you are right.
We keep track of your score to give you bragging rights against your peers.
This question is worth
3 points in this category: Encryption.
We'd love to give you credit for your own question and answer.
To submit a QOTD, simply log in to the
SQL Server Execution Plans shows you what's going on behind the scenes in SQL Server. They can provide you with a wealth of information on how your queries are being executed by SQL Server, including: Which indexes are being used, and where no indexes are being used at all. How the data is being retrieved, and joined, from the tables defined in your query. How aggregations in GROUP BY queries are put together. Grab your copy today from Amazon!
Yesterday's Question of the Day
(by Steve Jones):
True or False: You can run SQL Server in your existing data center and store data files for a database in the Azure cloud storage?
This is true. Starting with SQL Server 2014, you can store your data files in Azure for a SQL Server running on your premises.
If you're ever stuck in a situation where you want to unpivot a table even a temp table this SP will solve your problems.
The sp takes 3 arguements. The first being the name of the table that you want to unpivot, an optioinal second paramenter for the tableSchema. By default the SP will use the dbo schema. Finally, the third parameter is an output paramater to capture any errors.
There is only one prerequisite. The table you want to unpivot must have primary key(s). If not the SP will have no idea what to pivot on. It needs the primary key to normalize the table. The output is a table with the primary key(s) as columns and two additional columns called columnName and value. The columnName column will contain all the pivoted column names and the value column will contain all the columnName values.
Since a null value can't be unpivoted all nulls are translated to a blank string. Also, since the source of the data in the value column could be any datatype all datatypes are translated to a varchar(255) string. Simply, update the SP if you need a longer string value. Obvioulsy, you will not be able to unpivot a text, image, xml datatype datatype.
So, if you're ever stuck with having to compare a wide pivoted out table between two databases, simply run the unpivoter on each table, store the results in two temp tables. Then you can simply join the two tables on the primary key and list out all the diffs.
This newsletter was sent to you because you signed up at SQLServerCentral.com.
Feel free to forward this to any colleagues that you think might be interested.
If you have received this email from a colleague, you can register to receive it here.