Before you report your conclusions about your data, have you checked whether your 'actionable' figures occurred by chance? The Kruskal-Wallis test is a safe way of determining whether samples come from the same population, because it is simple and doesn't rely on a normal distribution in the population. This allows you a measure of confidence that your results are 'significant'. Phil Factor explains how to do it.
2017-07-27
6,123 reads
Technical debt is a real problem in database development, where corners have been cut in the rush to keep to dates. The result may work but the problems are in the details: such things as inconsistent naming of objects, or of defining columns; sloppy use of data types, archaic syntax or obsolete system functions. With databases, technical debt is even harder to pay back. Robert Sheldon explains how and why you can get it right first time instead.
2017-07-25
5,860 reads
User-Defined Functions (UDFs) are an essential part of the database developers' armoury. They are extraordinarily versatile, but just because you can even use scalar UDFs in WHERE clauses, computed columns and check constraints doesn't mean that you should. Multi-statement UDFs come at a cost and it is good to understand all the restrictions and potential drawbacks. Phil Factor gives an overview of User-defined functions: their virtues, vices and their syntax.
2017-07-21
5,686 reads
If the design of a relational database is wrong, no amount of clever DML SQL will make it work well. Dr. Codd’s Information Principle is that you have, inside the entity tables, the columns that model the attributes of that entity. The columns contain scalar values. Tables that model relationships can have attributes, but they must have references to entities in the schema. You split those attributes at your peril. Joe Celko explains the basics.
2017-07-18
3,822 reads
2017-07-17
1,269 reads
2017-07-13
1,032 reads
2017-07-11
1,185 reads
2017-07-06
1,312 reads
TSQL Code must work properly and efficiently. That's not enough though. Unless you are working alone, have perfect memory and plan to never change job, then you need to comment and document your code, it must be inherently readable, well laid out, use informative and obvious names, and it must be robust and resilient; written defensively. It must not rely on deprecated features of SQL Server, or assume particular database settings. Robert Sheldon starts a series of articles that explains the basics.
2017-07-05
7,732 reads
2017-06-28
1,099 reads
Every organization I talk to has the same problem dressed up in different clothes....
By DataOnWheels
I am delighted to host this month’s T-SQL Tuesday invitation. If you are new...
By alevyinroc
Ten years (and a couple jobs) ago, I wrote about naming default constraints to...
Comments posted to this topic are about the item The day-to-day pressures of a...
Comments posted to this topic are about the item Using OPENJSON
Comments posted to this topic are about the item Data Modeling with dbt for...
I have some data in a table that looks like this:
BeerID BeerName brewer beerdescription 1 Becks Interbrew Beck's is a German-style pilsner beer 2 Fat Tire New Belgium Toasty malt, gentle sweetness, flash of fresh hop bitterness. 3 Mac n Jacks Mac & Jack's Brewery This beer erupts with a floral, hoppy taste 4 Alaskan Amber Alaskan Brewing Alaskan Brewing Amber Ale is an "alt" style beer 8 Kirin Kirin Brewing Kirin Ichiban is a Lager-type beerIf I run this, what is returned?
select t1.key
from openjson((select t.* FROM Beer AS t for json path)) t1 See possible answers