SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Houston, we have a problem


Houston, we have a problem

Author
Message
Phil Factor
Phil Factor
SSCarpal Tunnel
SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)

Group: General Forum Members
Points: 4660 Visits: 3031
Comments posted to this topic are about the item Houston, we have a problem


Best wishes,

Phil Factor
Simple Talk
RobertYoung
RobertYoung
SSC Veteran
SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)

Group: General Forum Members
Points: 238 Visits: 232
I find I agree with the entirety of this post, especially the "failure" of Oslo. I had much hope that M$ would be the wedge factor to get us to database driven design. Sigh.

The amusing part: I spent the better part of a decade working for CSC, in a branch of the Financial Services group. We not only never got to use Catalyst (or ERwin or Rose), my colleagues' idea of design was to fire off DCLGEN. I felt so much like that shoemaker's kid.
gavwat
gavwat
SSC Rookie
SSC Rookie (32 reputation)SSC Rookie (32 reputation)SSC Rookie (32 reputation)SSC Rookie (32 reputation)SSC Rookie (32 reputation)SSC Rookie (32 reputation)SSC Rookie (32 reputation)SSC Rookie (32 reputation)

Group: General Forum Members
Points: 32 Visits: 77
Houston is the starting point for a Silverlight version of SQL Management Studio (which you can still use on your SQL Azure instances).
rbalmf
rbalmf
Grasshopper
Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)

Group: General Forum Members
Points: 16 Visits: 26
Yes I entirely agree with gavwat - either you have completely misunderstood the aims of Houston or (more likely IMHO) there is a smidgeon of faux-outrage in this editorial

And at the risk of fanning the flames further I would say that we shouldn't be designing applications from a database perspective anyway, we should starting at the front-end then identifying domain models and behaviour as this gets you closer to the use cases you are trying to fulfil. From this perspective heavyweight database design tools don't make sense at all.
RobertYoung
RobertYoung
SSC Veteran
SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)

Group: General Forum Members
Points: 238 Visits: 232
Quite wrong. That's the way your grandfather wrote his COBOL programs against VSAM files. What you propose is to turn RDBMS (SQL Server in this venue) into dumb files. What a waste of money.
rbalmf
rbalmf
Grasshopper
Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)

Group: General Forum Members
Points: 16 Visits: 26
Sure, we've invested so much money and 10 hard years learning this stuff that we just have to use it right?

You're entitled to your opinion of course, strange COBOL analogy notwithstanding, but if you look at the rise of cloud environments more widely you will see that there is a shift happening towards simpler storage models (BigTables, Azure Tables etc.) because they scale more easily and don't require DB Ninjutsus to get the best out of them.

I'm sure there will still be a place for you Old-Skool data guys but that place will be within the cloud, maintaining the platform, not developing software.

And I for one will be glad. Smile
rwatson-830107
rwatson-830107
Forum Newbie
Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)

Group: General Forum Members
Points: 8 Visits: 13
I'm too simple to understand all the implications of the discussion so far, but I do know that as soon as I see the words "simpler database design", someone has underestimated the problem, badly!

However, having said that, let me say this ... :-)

Smooth. efficient graphical representation of all aspects of a business application are even more critical today than they were in COBOL era's. The complexity and size of even "medium" applications, (especially involving a web environment), mean that we need to be able to overview huge wodges of development, all the inherent relationships and processes - quickly, and then be able to zoom in to the infinitesimally smallest unit.

There just isn't the time to page through, or 'text search' pages of code to sort out problems and plan new components. If the project has 2 man years or so of development, its just too complicated and big to fit in one brain - so the computer has to show the whole picture .... as a picture!

So, I won't be complaining about any graphical improvements, but at the same time my experience with Microsoft is the same as the writer of the article - lots of pretty pictures, but it falls over badly (metaphorically and physically), when any pressure or real detail is applied to their GUI.

If only Bill gates would stop this nonsense about curing AIDS - maybe we could afford to develop a truly awesome environment ! :-P
Phil Factor
Phil Factor
SSCarpal Tunnel
SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)

Group: General Forum Members
Points: 4660 Visits: 3031
you have completely misunderstood the aims of Houston

If so, I apologize. In the editorial, I'm just giving an initial reaction to the CTP based on what a developer in a corporate context might be aiming for with a SQL Azure development, and expecting to be able to do.

I'm not entirely sure that the overwhelming demand is for simpler storage models in the cloud. It would certainly make life a lot simpler for implementation if there was. I'm quite interested in Quadrant's approach in that it aims to go beyond the simple table model to allow the editing of hierarchies and structured data. I'd also make the simple intuitive bulk loading of table data via the Houston interface a requirement given the scale of the data that is likely to be required for a production system. However,in the editorial, I was merely trying to argue that a top-down diagrammatic approach to creating Azure databases might actually be an easier route to a success than one that is based from the start at the table-level. An approach that allows the creating, editing, etc.. of tables is necessary of course, but surely not sufficient.


Best wishes,

Phil Factor
Simple Talk
EdVassie
EdVassie
SSChampion
SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)

Group: General Forum Members
Points: 13111 Visits: 3893
There are a couple of viewpoints I could take over Houston...

1) The missing functionality is serious, and the product is of little use to the enterprise without it.

2) The available functionality is pointing the way to the paradigm of how we should work in the cloud. Life in the cloud could be much like Access - quick and easy to do simple things, a pain in the neck for anything complex. So this means we need to think simple when working in the cloud, and look at how database designs can be simplified.

As a Database Architect it horrifies me a bit that the DB is becoming little more than a dumb data store, but the bean counters are seeing the cost savings of cloud and putting on the pressure and DB professionals need to know how to design optimally for the functionality that does exist.

Original author: SQL Server FineBuild 1-click install and best practice configuration of SQL Server 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005. 14 Mar 2017: now over 40,000 downloads.Disclaimer: All information provided is a personal opinion that may not match reality.Quote: When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist. - Archbishop Hélder Câmara
RobertYoung
RobertYoung
SSC Veteran
SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)SSC Veteran (238 reputation)

Group: General Forum Members
Points: 238 Visits: 232
EdVassie (8/2/2010)

As a Database Architect it horrifies me a bit that the DB is becoming little more than a dumb data store, but the bean counters are seeing the cost savings of cloud and putting on the pressure and DB professionals need to know how to design optimally for the functionality that does exist.


We need to teach the bean counters, and the cloud providers, that the sea change isn't cloud (its grandparent being the Service Bureau, circa 1970), but rather the SSD/multi-core machine. Relational databases aren't supposed to be "simple" minded; they're supposed to express the data and its constraints in a logical, compact, and centralized fashion. These machines support, for the first time, BCNF datastores with more efficiency than HDD machines do flatfile systems. "Applications", however many, then query the data in any manner they wish. The downside, as always has been, is to Application Programmers (those descendants of COBOL programmers) who insist on doing ACID in client code; they just aren't needed, so it's the bread line for them. This way be dragons. There's a reason that enterprise, especially but all commercial, software is buggy and hated. Client coders do contradictory and silly things off-the-cuff to the data, on the assertion that the data belongs only to their application. And, of course, it doesn't.

Too many cooks spoil the broth.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search