Microsoft shakes SQL Server 2012's business end at big data
Still holding out for Hadoop
Review Those not in “Denali Denial” will be interested in SQL Server 2012, which has just been unwrapped and is currently being delivered to manufacturers.
In this review (I used Release Candidate 0) I’ll focus on how the new database looks, feels and compares with the existing server. I’ll also take a look at how SQL Server's big data integration stacks up, not only against the current version but also against comparable offerings from rivals.
The good news from SQL Server Management Studio is that the 2012 databases look and feel very much as they did before, so those GUI skills you've acquired as well as your muscle memory of driving the previous product are going to be largely transferable.
The bad news is that the kludgy bits of the 2008 R2 GUI are still with us. When, for example, are we going to get a database diagrammer that actually aligns the end of the joins to the primary and foreign key columns? This is not algorithmically complex, would not affect the muscle memory and would aid readability enormously. Sigh.
SQL Server 2012 comes with SQL Server Developer Tools (SSDT) (codenamed Juneau). It essentially packages together the BIDs tools – SSRS, SSAS and SSRS, which are recognisable as some of the high-end tools formerly available in Visual Studio – with a new service, Database Services.
The database service essentially works with a model of the database. So what? Well, think about the simple (but dangerous!) act of dropping a table. In previous versions of SQL Server you would have to work out the dependencies and deal with them first. Alternatively, you could try to delete the table, see what error messages were thrown up, interpret them and then make decisions about what you needed to do in order to get to a stage where you could delete the table.
Database Services can tell you what dependencies exist; what the likely consequences are (data loss is probably going to be high on the list); and then generate a script to do the work for you should you decide to proceed. Don’t do this at home, kids, and certainly not at work (on a production server).
As with so much here, this description just touches the surface; if you are interested in doing integrated, more controlled database development work in SQL Server, SSDT definitely warrants investigation.
One relatively significant change in the new Microsoft world of BI is that data for analysis can be stored in cubes (as before) but also in tabular form. This has prompted a raft of requirements, technologies and so on, which can hold and perform rapid analysis on tabular data – for example in-memory storage and column storage. This, in its turn, has led Microsoft to talk about the BI Semantic Model (BISM).
BISM is not a product any more than the UDM (Unified Dimensional Model) was a product, it is simply a way of addressing the need to talk about/describe data held in either format. As such I think it is a great idea; but then I liked the UDM as well.
And for the BI end users there is PowerView (formerly known as Project Crescent). Imagine, if you will, a browser-based, Silverlight application that can connect to a besom model based on tabular data held in Analysis Services.
Next page: Flavours to savour
What's new, as a DB?
Anyway, here goes the moaning:
Fix the bugs first.
The fact that I've found that an emacs script to convert csv to insert statements works more reliably than the other data import facilities (which can't even handle csv correctly) is damning. Excel can, why can't it's import wizard?
In 2k8 BOL is unclear about fairly important aspects of the geographical extensions. Cost me quite a bit of time, did that. Very embarrassing when your stuff is pushed live and it breaks (except that it didn't, it was undocumented behaviour to do with geog algorithms being approximate, documented nowhere). Have they documented their stuff, old and new, fully?
Also, if I haven't mentioned this before, fix the bugs. The triple-join-in-a-view which bombed the server... thanks. More time wasted.
On to your review, then.
It seems to discuss a load of stuff built of top of an sql server as a platform, not db functionality per se.
That stuff about dependencies, what's wrong with sp_depends? Or right click on the object explorer and pick 'view dependencies'
And I hope you were joking about the silverlight add-in.
I'm rapidly losing my trust in MS' db products.
(Gripe over. Thank you for listening)