Book Review: The Hard Thing About Hard Things

I recently read The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers by Ben Horowitz. I was interested to read it because Ben is a well-known and experienced entrepreneur, based in the Silicon Valley area south of San Francisco. He offers advice on how to really run startups.

I loved the way that Horowitz addressed failure. Instead of taking the business school approach of telling you how things should be done, and assuming that you'll do everything correctly, he spends time telling you what to do after you've already screwed up.

I thought the advice that he delivers is quite realistic, and more importantly, helpful. It was interesting to see him asking you to embrace the struggle.

Many CEOs that I talk to feel like they're the only ones who must be struggling, and they often feel quite alone. Horowitz makes it very clear how much everyone in these roles struggles, and then provides ideas on what to do when you're in lousy situations.

Overall, I found this refreshing, and honest.

Bottom line?

This book is interesting and is certainly worth your time if you're looking to run a startup, or if you are already struggling to do so.

Greg's rating: 8 out of 10

Note: as an Amazon Associate I earn (a pittance) from qualifying purchases but whether or not I recommend a book is unrelated to this. One day it might just help cover some of my site costs. (But given the rate, that's not really likely anyway).

Shortcut: Accessing script files and folders in SQL Server Management Studio

This one is a very simple and quick tip.

When working in SQL Server Management Studio (SSMS), I often need to open File Explorer in the folder where the script file is stored. Turns out there is an easy way to do that.

There are two interesting options when you right-click the tab at the top of a query window:

Note that you can open the containing folder for the script. You can also copy the path to the script into the clipboard.

SDU Tools: Screaming Snake Case and Sponge Bob Snake Case in T-SQL

In our free SDU Tools for developers and DBAs, a number of the string formatting functions have been quite popular, and we keep getting requests for even more.

Today's post highlights two of these. Screaming Snake Case is words in capitals separated by underscores. Sponge Bob Snake Case has underscore separated words (hence the "snake case" part) with alternating capitals. (It's just for fun).

You can see them (and some others) in action in the main image above, and in this video:

To become an SDU Insider and to get our free tools and eBooks, please just visit here:

http://sdutools.sqldownunder.com

SQL: The Down Side of a Low FILLFACTOR

When you create or rebuild an index in SQL Server, you can specify a FILLFACTOR value. It determines how full (as a percentage) that SQL Server should try to make the pages.

There is also one special value. Zero says "I haven't set a value" and it applies the default, which by default, is 100%. Any value from 1 to 100 is the target percentage.

So why do people set lower values for FILLFACTOR? The argument is they know that their inserts are going to happen all over the table (i.e. not just neatly at the end of the table), and they're trying to avoid page splits. And yes, lots of page splits can be a nasty thing. The most common problem case that people describe is where they've used a GUID as a clustering key (usually also a primary key) for a table. Then the inserts happen randomly throughout the table.

Now many applications do this with all their tables. SharePoint is one of the applications that has made database decisions that I really, really don't like. Because they used GUID keys all over the place, they just routinely make all the indexes have a 70% FILLFACTOR. That's really sad.

The problem with low values is that your data is spread across more pages, so you have to read more pages to get the same amount of data.

If you set a 50% FILLFACTOR, you now have to read twice as many pages to get the same amount of data.

And this is where the pain really occurs. Most systems spend the vast majority of their time reading, not writing. The time it takes for writes to occur might be important, but if you're going to optimize most SQL Server systems today, you need to be optimizing for reads.

And that's exactly the opposite of what you're doing with a low FILLFACTOR.

I often hear people discussing the proportion of writes on most systems. People assume that systems will spend 10 or 20% of the time writing. I had a lengthy discussion with a Microsoft product group member who told me that he thought even 40 or 50% was common. I've worked on these systems a long time, and I can assure you, that's not common.

Every time I measure the proportion of writes on systems, I typically see numbers like 1%. So you have to ask yourself if you want to optimize for the 1% or for the 99%. 

I'm not underestimating the pain that a large number of page splits can cause but you need to be really sure that that's your biggest issue before you start dropping FILLFACTOR values. And you certainly never want to do it as a blanket rule across all your tables and indexes.

 

T-SQL 101: #7 How are users different to logins in SQL Server?

One concept that often confuses newcomers to SQL Server is the difference between a login and a user.

In an earlier post, I mentioned that being authenticated to a server is what's called a login. In this example shown, I have a log in here called Malathi. But as I said, this means nothing about what databases Malathi then has access to.

The connection between a login and a database is what the concept of a user is about.

It may seem a little strange at first that a login has a name, yet in each database, that same login could have a different user name. But a  database user is a sort of a mapping that says that login is called this name.

Malathi is the login still but it was authenticated as that and in this first database is the user dbo (which is actually short for database owner). In the next databases, Malathi has the username Mala and is treated as that user throughout that database.

Now obviously it's far simpler if the user name is the same name as the login. And that's the situation with the last database shown.

Now there are 3 common types of users: the first is a log in who's been granted access to a database. That's the same as we've shown in this diagram.You can also have a Windows group that's been given access so for example, we might have in Windows, a SalesPeople group and that group could be given access to a database. Then if Tom is a salesperson, Tom would have access to that database because of his Windows identity and group membership.

The final option is that since SQL Server 2012, we can also have a database that does the authentication instead of the server. That's a very special case, called a contained database. It's not very common. But what it does is it allows the user to connect to one database and have no access to anything else on the server.

Learning T-SQL

It's worth your while becoming proficient in SQL. If you'd like to learn a lot about T-SQL in a hurry, our Writing Queries for SQL Server course is online, on-demand, and low cost.

Learning Mandarin: More direction words

Another useful group of words that I learned are used to describe the position of something.

Here are the most common:

上 (Shàng) is up or on
下 (Xià) is below or under

前 (Qián) is in front
后 (Hòu) is behind

旁 (Páng) is beside

里 (Lǐ) is in (like inside)
外 (Wài) is out (like outside)

右 (Yòu) is right
左 (Zuǒ) is left

Often these words are used with either 边 (Biān) or 面 (Miàn) to indicate the position. Both seem to be able to be used interchangeably, but I know most of my Taiwanese friends seem to use 面 (Miàn) most of the time, except they seem to always use 边 (Biān) for left and right.

You'll often hear these after a noun, to indicate a position, in relation to the noun. So

房子后面 (Fángzi hòumiàn) will be "rear of the house".

镜子前面 (Jìngzi qiánmiàn) is "in front of the mirror".

Learning Mandarin

I'll write more soon on the best methods for learning. If you want to get a taste for it in the meantime though, my current favorite is Tutor Ming. If you decide to try it, click here and it's a bit cheaper for you, and for me.

Book Review: The Little Things: Why You Really Should Sweat the Small Stuff

The title of this book caught my eye. I'm sure it's intended to be a play on the title of  Don't Sweat the Small Stuff and it's all small stuff: Simple Ways to Keep the Little Things From Taking Over Your Life by Richard Carlson. I reviewed that book here.

So this one is The Little Things: Why You Really Should Sweat the Small Stuff by Andy Andrews.

Andrews tends to write small (and short) books that get pretty much to the point. This one also does the same. I saw a large number of people taking about how much they enjoyed it, but for me, it fell flat. In Carlson's book, there were great messages about how easy it is to have your life overcrowded, particularly with things that in the end really don't matter.

Andrews takes the opposite view that so many of these little things really are critical. He spends ages talking about how an air rifle played a key part in the Lewis and Clark Expedition, and how a handful of nails was critical in the Battle of Waterloo.

We've all seen situations where significant things fall apart for the lack of attention to small detail. And Andrews clearly shows examples of this.

It's a pretty quick read, and at least he doesn't belabour the points.

I just ended up feeling pretty unconvinced, but noting other reviews, I seem to be in the minority. I just didn't find any real revelations here.

Greg's rating: 6 out of 10

Note: as an Amazon Associate I earn from qualifying purchases but whether or not I recommend a book is unrelated to this. One day it might just help cover some of my site costs. (But given the rate, that's not really likely anyway).

 

Shortcut: Using Quick Launch in SQL Server Management Studio

In SQL Server Management Studio (SSMS) for SQL Server 2016, a new search tool called Quick Launch was added. It's this bar up the top:

Note that there's another bar underneath it to the left. That's not the Quick Launch bar. That's the Find bar.

While the Find bar is useful for searching for text within queries, etc., the Quick Launch bar is useful for searching within SSMS itself.

This is great because it means you don't have to remember where all the options for various things are set. Here's an example:

I typed theme and it told me about relevant things. The first is spot on, and is where I can change the theme, and the second is relevant too. Perhaps it's just the fonts that I want to change.

SDU Tools: XMLEncodeString and XMLDecodeString in T-SQL

On occasions, I need to work with XML data in SQL Server T-SQL and one problem is that I need to be able to encode and decode strings, using the XML encoding standards. For example, my strings might include % characters or < or > characters, etc.

So we added a pair of tools (XMLEncodeString and XMLDecodeString) our free SDU Tools for developers and DBAs.

You can see them in action in the main image above, and in this video:

To become an SDU Insider and to get our free tools and eBooks, please just visit here:

http://sdutools.sqldownunder.com

SQL: Text vs Varchar(max) – in row vs out of row storage

There was an interesting discussion on a local mailing list about the performance of a table that was just used for logging. One of the things that intrigued me was that the developer had used the text data type to store his log messages.

Now text, along with ntext and image, was deprecated back in 2005. Instead of text, ntext, and image, you should be using varchar(max), nvarchar(max), and varbinary(max).

The way the data is stored was also changed. The old data types used to store their data out of the table's data rows, and just store pointers within the table's data rows. This can be really slow. By comparison, the new types default to storing the data within the table's data rows, and using overflow pages if need be. For many applications, this can be much faster. Simple writes to the end of a log file are a good example of that.

The problem with this is that you can't just change the data type of a column from text to varchar(max). If you do that, the data won't get moved in-row. You need to rebuild the table.

Let's take a look at an example. I'll start by creating two tables, one using text; the other using varchar(max):

Then we'll populate both with 10,000 rows of data:

Finally, we'll query to see where the data was allocated:

Note the one table is significantly smaller and only has in-row data.

Let's try altering the column to change the data type:

And check again:

You can see that nothing has changed. Now let's try rebuilding the table:

And still no prize. So we'll do it the hard way:

And then we're happy: