Microsoft’s Newest and Largest Retail Store, with a Bit of Hockey

Today I was a guest of Microsoft for the opening of their newest store in Yorkdale Mall in Toronto.  This is their first non-US store and the largest Microsoft retail outlet in the world.  So far.

There were already about 500 people in line to see the new store when I arrived about 8AM for the 9 AM opening.  After indoor fireworks and confetti cannons, the Microsoft Canada president Max Long announced that they were donating $1.5 Million to local Toronto charities – $250k each to Evergreen and Girls and Boys Club plus $1 million to Junior Achievement.  I think this is a wonderful way to celebrate an opening.

Right now I’m live blogging from a Sony Windows 8 Touch Ultrabook.  It’s a sexy beast of a machine – 3.5 lbs, i7, 6GB and a touch screen.  I was doubtful about the touch screen part, but I think it make sense for some application.  Not now while I’m blogging, but as I uploaded my photos for this post, being able to use a touch interface was great.

Right now people are starting to line up to play Kinect with Wayne Gretzky. 5 hours early.  I can’t wait….

Some more pics of events so far:

Friday Fun Contest: How Many TLAs Can You Fit In a Sentence?

It’s Friday again (we should have more of these) and I’m in the mood for a contest.  I have some mystery prizes, more than just swag, to give away.  But I’m not saying what it is until the contest is over. Let’s just say it will have data stuff, space stuff, and for certain one of those secret Canadian keychain bottler openers.  The value of the prize will be approximately $100… CANADIAN!!!!…which I think now is close to $100 million dollars USD.

How Many TLAs can you fit in a sentence?

Your challenge is to make a  grammatically-correct sentence that is dominated with TLAs.  What’s a TLA?  Why it’s a Three Letter Acronym, of course. But we’re going to be flexible.  You can use acronyms or initialisms and you aren’t limited to three letter ones.  You can also tack on verb endings and such. So things like RBARing, LOSed and SSDTed are fine.  We’ll have a group of prestigious fun judges to evaluate your submissions based on these guidelines:

• Length of sentence
• Length of TLAs
• Higher ratio of TLAs to “real” words – in fact, I want to see very few real words
• Higher weight given to non-product TLAs
• Originality is a real plus
• Higher weight given to a good mix of TLA “domains”.  If you can work in textspeak, space, tech, music, literature, arts and crafts, cycling and knitting, then you’re golden.
• The more snark the better.

Your TLAs should be commonly known or easily to lookup.   If we can’t figure out what it means, you’ll lose points.

Examples

I REd a CRM DB to get the DDL for the CASE tool, FTW.

OK, my C4ISTAR PM FUBBARed* my PLoA due to a SNAFU* with a SME's PEBCAK bug.

NASA SCUBA SMEs are NEEMO FTEs, AFAIK.

The Rules

Entries accepted from locations where these sorts of contests are legal.  Check with local authorities.  If you are unable to accept the prize for a corporate or government restriction, just let us know.  We’d still love to honour your work.  Canadian residents must solve a particularly silly mathematical question.  Study up on square roots and factorials. But they won’t be in the question.

Decisions of the judges are final.

You must be 13 years of age or older to enter.

You agree to let us publish your entries, but you get to keep ownership of them.  We are nice like that.

Your sentence must be an original creation, by you.

No explicit, illegal or shameful content.  Yes, I know some of you are disappointed.

Contest closes on 29 October 2012, 2 November 2012 at midnight my time, wherever I am at that time.

* UPDATE * I’ve just received some new swag from vendors, so I’m extending the deadline for this contest.  We will now have 3 prizes to give away. *

Taxes, customs, duties and any other silly mandated stuff that makes it less fun to win are the responsibility of the recipient.

*The TLA example above has alternate, family-friendly definitions.  I looked them up. Trust me.

How to Enter

Leave your entry here as a comment.   Yes, you can enter more than once…let’s say no more than 4 entries per person.  Yes, you’ll have to use a method to post that allows us to contact you to arrange for the major award.  You can submit anonymously, but no prize for you.

The Judges

Denny Cherry (@mrdenny | blog ) Unofficial SQL PASS Party Planner and Trouble Maker

Joey D’Antoni (@jdanton | blog ) Biker, but not that kind, who architects on the side

Marco Frissen (@mfrissen | blog ) Opinionated space and tech geek. Token foreigner on this panel

Thomas LaRock (@sqlrockstar |blog ) DBA, Happymaker, and bacon lover

Shannon Moore (@ageekmom | blog )  SpaceTweep Wrangler and cyclist extraordinaire

Karen Lopez (@datachick) Loves Space and Data.  Almost the same. But Space Data is best. Another foreigner, sort of.

Metadata Stuffing: Why I Hate tbl_ for Table Names

This week was Canadian Thanksgiving so this post on metadata stuffing is timely.

Today Thomas LaRock (@sqlrockstar | blog ) posted a rant about our Database Design Throwdown topic on naming standards for tables and other database objects.  Tom is a fan of what I call “metadata stuffing” in object names.  That’s basically shoving as much additional information as one can into object names so that one does not have to go find out that information from its rightful place.

My reason for wanting to use prefixes is simple enough: I want to know if I am looking at a table or a view when reviewing code.

Karen doesn’t believe that anyone should be using object names as a place to store meta data about the objects themselves. I would like to agree with her but then we’d both be wrong.

He even created the nice graphic of my quote I use here. Thanks, Tom.

Object Confusion Abounds

That quote is indeed one I use during our debate.  It’s a snarky introduction to what I think the real problem is: our tools aren’t doing enough to help us with this potential confusion of tables and views.    When you are writing or looking at a query, the syntax for referencing a table or a view is exactly the same.

When a developer writes:

USE AdventureWorks;
GO
SELECT Name, ProductNumber, ListPrice AS Price
FROM Production.Product 
ORDER BY Name ASC;
GO

He has no idea for certain if Product is a table or a view.  The syntax is the same.  And if the developer is working in a text editor of some sort, or with some native tools, there’s no tooltip or other help that the he can use to check what type of object they are querying.

Why does this matter?  Tom has a great presentation where he shows the impacts of trying to make stuff work and you don’t know what you are looking at.  That’s why Tom wants to do this with his objects:

FROM Production.tbl_Product

or

FROM Production.view_Product

So that the object type is injected into the object name.  That seems so innocuous, doesn’t it?  What could go wrong?

I’m here to tell you that this is a slippery slope.  One of the most egregious examples of this sort of meta data stuffing I’ve run across is one that required all this meta data to be prefixed in front of every table name:

• tbl_ prefix
• Primary Systems that managed the table
• Primary subject area that the table belongs to in the data model
• Classification of the role the table plays in the database (Associative Entity, Domain Entity, Master Data, Reference Data, Log Data, etc.)
• Three letter login of the DBA responsible for administering this table (I KID YOU NOT).

So in this wonderful naming scheme, we’d get:

FROM Production.tbl_MFGR_ORDERPROC_DOM_KQL_Product

I have found that once an organization starts thinking of stuffing, their designs become turkeys really fast.  It’s ugly.  Think about the tools you use, with all those nifty object lists on the left side. To find a table you need to know all that great metadata as you scroll through the list, hoping that PRODUCT Is buried in there, somewhere.  And what the heck was the name of that guy that dressed funny who did all that data stuff for the company before he won the lottery?

All that metadata that should have been managed elsewhere, not prefixed in front of the “real” name of the table.  In fact, it was.  In the data model and in the system catalog. Every time any of that data changed (DBA assignment changes, DBA wins the lottery, whatever), we had to rename the table and change all the code and reports that referenced it.  Sure we could have isolated systems by this change by using views and or aliases but that is additional complexity for no performance gain, either.  Refactoring might have helped, but eventually we’d still have to change all the code and queries.

Why I Hate Metadata Stuffing

1. It’s redundant data.  Just like with business data, the reason we want to minimize redundant data is because we then have to worry about updating the data in multiple places. There’s cost and added risk for that.
2. It changes.  I don’t know about you, but I don’t have the luxury of taking down a production system just to update  a change in the name of the DBA’s favourite TV show or whatever lame naming scheme someone thought up. Sure, tables can’t change into views or indexes, but all the other type of stuffings will change.
3. It takes up real estate. I get all kinds of flack from developers and DBAs for the length of object names when I want the names to be meaningful.  It’s funny how spelling out CUSTOMER is unacceptable, but adding the exact same characters in front of every object of its type is A-OKAY.  What’s up with that?  Somehow optimizing names for developers is more important than loving your data?  Show me where it says that in the Project Charter.
4. tbl_ is a tell for bad database design.  I don’t know where this particular naming scheme originated, but when I do a database design review and I see this naming scheme, I know that the designer learned design in a one hour webinar “training course” and has not really mastered the complexities of enterprise database design and maintenance. The design will be less than best practice 90% of the time.  This naming scheme is prominent in programming books, introduction to database books, presentations by non-database people, and uninformed blog posts, by far.  It’s not popular with people who do professional database design. Sure, some products use this, too, but do you really want to take database design best practices from vendors? How many professional data architects do you think they have on staff?  I will most likely see a database design that is highly optimized to make development go faster.  Not for data integrity or loving data.
5. It’s not needed “for consistency”. One of Tom’s points is that if we are going to prefix views, we have to prefix tables to be consistent.  Actually, no, we don’t.   If we have to bite the bullet and prefix views because our tools let us down, we can choose not to clutter up tables names just to punish those objects, too.  I’m assuming that since Tom prefixes tables and views, he prefixes columns, too, right?  its just being consistent.  < snort>
6. It gets in the way of using the data. Tables and Column names are the most user-facing parts of a database design.  When we in IT insist on munging up these names with a bunch of systemese, we make it more difficult for business users to get at their data.  It shows that we have optimized the database design to help a relatively small number of technical users (developers, DBAs, ETL folks) over the needs of the business.  Ultimately, we build databases to manage data.  For the business.

What’s the Cost, Benefit and Risk?

One of my Splendid Truths is that all design decisions should assess cost, benefit and risks.  In the overall scheme of things, just prefixing “tbl_” in front of a table name isn’t that costly and it isn’t that risky.  Tom assesses his designs based only on potential for performance harm according to his post.  He “laughs” at my position.  I’m happy that my stance on metadata stuffing brings happiness to his day.  But performance is only one data point out of many for making a design decision.  Usability, clarity, business goal support are other factors that a database architect needs to consider when assigning a name to an object.  If we optimize something for a subsystem, we do it as the expense of other subsystems.

Our Tools Should Help Us More

Having said that, I feel the pain of people having to work with sub-standard tools or having to use tools that just refuse to help.  Tom showed how SQL Server Management Studio tooltips can help.  But all those command line “I don’t need any stinking help” aficionados are left on their own to know what they are looking at.

Oh, and Tom:

ProperNoun_Tom, Pronoun_you Verb_made Pronoun_me Verb_laugh Preposition_with Possessive_your Noun_post.

(See how all this stuffing gets in the way?)

One of my other Splendid Truths about database design is:

Your tools will impact your data models and database designs more than you can imagine.

We shouldn’t sit back and let that happen. Stuffing is great with Tofurky, not with databases.

Thinking This Might Be a Useful Set of Rules for PASS Summit Sessions…

Astronauts Know Everything…

Recently @VenusBarbie visited Europe for the ILATweetup and SpaceUPEU events.  I wasn’t able to go due to other commitments, so Rob had to take over escort duties for our traveling Astronaut Barbie (@venusbarbie | Technical Barbies on Facebook).  The truth of the matter is that we humans officially get the invites, but we know that it’s really the space mascots that are wanted due to their celebrity status.  Rob also took along a 2D version of Commander Chris Hadfield (@cmdr_hadfield), AKA #Chris2D

I have some other photos to share, but the set I found most interesting were those with European Space Agency astronaut Paolo Nespoli showing Rob how to ensure that Barbie’s hair is just right before a photo shoot:

I guess all that centrifuge training she did at the DLR comes in handy when she hangs with other astronauts.

Once VenusBarbie was set, then all four (Rob, Paolo, VenusBarbie and Chris2D) were ready to pose.

Good job, men.  And @VenusBarbie.

On This Day in 1983, Data Analytics Might Have Been a Fail

On 26 September 1983, Stanislav Petrov took a stand against what his systems were telling him and he may have changed the course of history.  Petrov was working as a duty officer at the command center for the Oko nuclear early warning system.  This is the place where the Soviets monitored incoming attacks, much like the US command center you remember from War Games.  Earlier that month, the Soviet Union shot down a Korean commercial jetliner over the Sea of Japan, claiming that it was on a spy mission.  269 people died in that incident, including a US Congressman.  Some at the Soviet Union were fearful of a retaliation strike by the US.  Cold War tensions were high.

At the command center, Petrov was getting data that a launch of five missiles had been made in the US towards the Soviet Union.  But instead of just reading that dashboard and acting he actually used his own inner analytics system to process the data and decide not to report or react.

Had Petrov reported incoming American missiles, his superiors might have launched an assault against the United States, precipitating a corresponding nuclear response from the United States. Petrov declared the system’s indications a false alarm. Later, it was apparent that he was right: no missiles were approaching and the computer detection system was malfunctioning. It was subsequently determined that the false alarms had been created by a rare alignment of sunlight on high-altitude clouds and the satellites’ Molniya orbits, an error later corrected by cross-referencing a geostationary satellite.^[5]

Petrov later indicated the influences in this decision included: that he was informed a U.S. strike would be all-out, so five missiles seemed an illogical start;^[1] that the launch detection system was new and, in his view, not yet wholly trustworthy; and that ground radars failed to pick up corroborative evidence, even after minutes of delay.^[6]

- Wikipedia contributors. "Stanislav Petrov." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 26 Sep. 2012. Web. 26 Sep. 2012.

I’ve always wondered if the system he was using had a bunch of fancy dashboard features, like shiny 3D pie charts, moving average lines and drill down capable reports if he would have been able to not trust the data.  I’ve seen this sort of over-trust of data with data model diagrams.  It seems the prettier or more advanced the presentation of the data is, the more people want to believe it is right.  In fact, I’ve learned to present draft documents to people on my teams with hand-written notes/comments on them to sort of "break the ice" to show people that they are drafts.  A modern solution might have included some sort of decision making guidance that say "Confidence Factor of Attack: 99%" or something like that.  And it would have been highlighted by some sort of red bar, showing just how confident the system was based on the data – bad data, it turns out.

More details about Petrov and his actions in the video above from History.com