This will be an EPIC event that you will not want to miss.
Join me and the rest of the Snowflake team at Data Cloud Summit 2020! This year we are going virtual with eight business and technology summit tracks, filled with never-before-seen demos, customer presentations, fun interviews, fireside executive chats and, of course, technical deep dive sessions.
This is a totally FREE event that will deliver:
All focused on using the Snowflake Data Cloud to #MobilizeYourData!
Mark this date on your calendar – November 17, 8:30 AM – 2:30 PM PT.
And if you miss any part of the event, sessions will be available for replay immediately after.
Yup I traveled a lot in 2019. Mostly in my role as Chief Technical Evangelist for Snowflake, but some for family vacations (yes I do take those!).
Inspired by good friend Jeff Smith, here is my travel report based on Google location services. Surprisingly accurate (should I be concerned?).
While traveling this much can be taxing (especially on my family), it is a blessing to be able to see all these wonderful places and meet lots of wonderful people as part of my job at Snowflake, even if it means being a #RoadWarrior.
By The Numbers
174 miles on foot!
There are more miles when I did not have my phone
This includes a great hike with my family all the way from Waikiki Beach to the top of Diamond Head and then back.
2 miles by bike – I know that was in Berlin using an Uber Bike (a very neat and useful concept)
14,450 miles by mass transit (cars, trains)
And then a lot more air miles!
Wow. That adds up to 7 times around the world for an estimated 173,475 miles! Yikes.
In 2019 I got to explore both countries and cities I had never been to before, as well as some fo my old favorites.
In the “never been here before” category:
Stockholm, Sweden – first time ever to Sweden! Even in January it was quite fun with lots of sites to see including the Viking Museum.
Dublin, Ireland – actually got to go there twice!
Lisbon, Portugal – LOVED the seafood!
Australia & New Zealand – I had two separate 2 week trips down under and got to see quite a bit, plus catch up with some old friends I had not seen in over 20 years.
I did manage to also visit places in the US where I have bene before like Dallas, Miami, Ft Lauderdale, Orlando, Santa Monica, Philadelphia, Honolulu (vacation), and Stowe (Vermont). I had LOTS of trips to San Francisco and San Mateo (where Snowflake HQ is located).
Outside the US, I got the pleasure of return visits to Rome (which I LOVE LOVE LOVE), Milan, London (2x), Amsterdam (2x), Utrecht (2x), Helsinki (Finland), and at the end of the year, a trip to snowy Montreal in Canada.
Where to next?
So where will I go in 2020? Stay tuned. The adventure continues…
Happy New Year 2020!
The Data (and Road) Warrior
P.S. One place I will be for sure in June is the Aria Hotel in Las Vegas where we will be hosting the 2nd Annual Snowflake Summit. We do expect it to SELL OUT again this year. Super Early Bird registration closes January 30th, so get your registration in today!
My good friend Mark Rittman has embarked on a new adventure as an independent analyst and consultant. As part of his new venture Mark started a new podcast series on iTunes that he calls Drill to Detail where he will feature interviews discussing a range of topics related to data warehousing, business intelligence, analytics, and big data.
I was honored to be asked to take part in this new venture and got to spend a hour with Mark a few weeks back recording what is now Episode 5 of the series. In this interview we talk about:
The need and relevance of data modeling in the big data world (which I wrote about recently)
A while back, I wrote a post about having FKs (foreign keys) in your data warehouse.
Well, a similar question came up recently on an Oracle forum with the above title. It is a fair question and it does surface fairly regularly in a variety of contexts (not just data warehousing).
Of course, as The Data Warrior, I felt is was my duty to respond.
Is there any reason to maintain a permanently disabled FK in the data model? I’m not envisioning a reason to do it. If it is not going to be enabled, then from my perspective, it would not make any sense to have it defined. If anything, provide the definition of the relationship in the comment of the child column.
Yes, by all means keep the FK please!
I see three good reasons for doing so:
It is valuable metadata (& documentation). If somebody reverse engineers the database (say with ERWin or Oracle Data Modeler), the FK shows up in the diagram (way better than having to read a column comment to find out)
A picture is worth a thousand words!
BI Metadata – If you want to use any sort of reporting or BI tool against the database, most tools will import the FK definition with the tables and build the proper join conditions. Way better than having someone guess what the join will be and then manually adding it to the metadata layer in the reporting tool. Examples that can read the Oracle data dictionary include OBIEE, Business Objects, COGNOS, Looker, and many others.(Note here that since the FK is not enforced on the remote databases, you might want to make sure these are treated as outer joins, lest you lose some transaction in the reports).
The Oracle optimizer will use disabled constraints to improve query performance of joins. Again, this is metadata in the data dictionary which the optimizer can read. This is documented in the Oracle Data Warehouse guide and I have validated it on multiple occasions with Oracle product management.
While #3 applies specifically to Oracle, for other databases like MS SQL Server and Snowflake, #1 and #2 still apply.
Even if only one of the above is true for a given database, that, in my opinion, still justifies keeping the disabled constraint around.
Final Answer = Wisdom
What do you think? Feel free to comment below.
And please share on your favorite social media platform!