Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Houston, we have a problem Expand / Collapse
Author
Message
Posted Saturday, July 31, 2010 1:08 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Monday, November 10, 2014 12:04 PM
Points: 590, Visits: 2,565
Comments posted to this topic are about the item Houston, we have a problem


Best wishes,

Phil Factor
Simple Talk
Post #961792
Posted Saturday, July 31, 2010 6:37 PM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Thursday, September 11, 2014 12:01 PM
Points: 76, 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.
Post #961828
Posted Saturday, July 31, 2010 7:26 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, November 1, 2014 2:56 AM
Points: 4, Visits: 69
Houston is the starting point for a Silverlight version of SQL Management Studio (which you can still use on your SQL Azure instances).
Post #961834
Posted Sunday, August 1, 2010 3:27 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, November 1, 2010 2:55 AM
Points: 6, 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.
Post #961866
Posted Sunday, August 1, 2010 1:03 PM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Thursday, September 11, 2014 12:01 PM
Points: 76, 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.
Post #961914
Posted Sunday, August 1, 2010 2:26 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, November 1, 2010 2:55 AM
Points: 6, 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. :)
Post #961931
Posted Sunday, August 1, 2010 7:47 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, April 26, 2011 11:34 PM
Points: 4, 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 !
Post #961966
Posted Monday, August 2, 2010 2:20 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Monday, November 10, 2014 12:04 PM
Points: 590, Visits: 2,565
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
Post #962027
Posted Monday, August 2, 2010 3:31 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, November 14, 2014 8:26 AM
Points: 2,894, Visits: 3,278
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 2014, 2012, 2008 R2, 2008 and 2005. 18 October 2014: now over 31,000 downloads.
Disclaimer: All information provided is a personal opinion that may not match reality.
Concept: "Pizza Apartheid" - the discrimination that separates those who earn enough in one day to buy a pizza if they want one, from those who can not.
Post #962045
Posted Monday, August 2, 2010 7:09 AM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Thursday, September 11, 2014 12:01 PM
Points: 76, 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.
Post #962162
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse