Category: SQLServerCentral

Post within this category are syndicated to www.sqlservercentral.com

TSQL Tuesday #108 – Learning to Learn

G’day,

One attribute that I think is more relevant today than ever is to have a broad base of skills with the ability to go deep when needed.

This requires the ability to learn quickly when needed.  Which, in turn, requires that we know how to learn quickly.

When I learnt SQL, I had the luxury of time and the ability to simply absorb things slowly, to buy and read books and build a todo list that might take a while to get finished. Those days are fading and a new era of learning is upon us.

Now we are at a point where learning from books (for a lot of things – but not all) is not the best way to go. This is  more of a function of how long it takes to write and get a book published –  often the content is out of date, even at publication time.

Now we are seeing technology changing that fast that even  blog posts and other online content is quickly being out dated. This means we have to be vigilant and look at dates associated with online content and judge if this content is of value any longer.

We need to have side projects where we can experiment, we need to network harder than ever and learn form our friends and peers, we need to share our knowledge and work in teams that have great learning cultures and are happy to experiment.

In summary, I feel the biggest skill that is needed today is the ability to learn quickly – and to have a good strategy to accomplish that. To recognise good  mentors, have good foresight and look for opportunities to take on projects that will elevate our learning.

Have a great day.

Cheers

Martin

 

 

A lack of foreign keys – a bad culture example.

G’day,

One of the things that I’ve been seeing more often than I would like to lately is large databases with no foreign keys – or minimal foreign keys (and often with those minimal set of keys disabled)

By large databases I’m roughly meaning databases with several hundred tables, and I usually see a lot of these tables with several hundred GB’s of data in them.

When I generally ask about the reason for no foreign key, I’m told

  1. they add  overhead
  2. they give no benefit
  3. we can’t enter our data properly when we have them

The last one in the above list is generally down to poor modelling – an example being entering a later part of a financial transaction before the first part of the financial transaction has taken place. Once both parts of the financial transaction have taken place then the database is left in a consistent state – BUT, that generally being handled by the app NOT the database – OUCH!

My first though here is “I’m glad I don’t use this company” – and I also wonder why auditing or testing has not picked it up. Quite often it has but somebody, somewhere has decided that there’s a reasonably low chance of that occurring and so no action has been taken – until the ‘bug’ is discovered sometime later and at that point takes a long time – and a lot of money – to fix.

Points 1 and 2 are quoted more often than I would like also – usually stemming from statements that were made by somebody who worked with a long dead version of the database and didn’t quite take the time to understand fully how relational databases work – but who had tremendous influence in the company and a reputation that meant they were not to be crossed. (they have since been proved wrong but have failed to accept it)

These are simply examples of now bad culture can lead to problems years down the road.

Looking at a lot of database that lacked foreign keys, it’s usually pretty simply to find examples of inconsistent data in the tables. – caused by the three issues above.

The moral of the story here is

Always question, always learn and really try to avoid issues that are bound to come back and haunt you.

Always try to build good culture.

Have a great day.

Cheers

Martin.