July 31, 2010 at 1:08 pm
Comments posted to this topic are about the item Houston, we have a problem
Best wishes,
Phil Factor
July 31, 2010 at 6:37 pm
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.
July 31, 2010 at 7:26 pm
Houston is the starting point for a Silverlight version of SQL Management Studio (which you can still use on your SQL Azure instances).
August 1, 2010 at 3:27 am
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.
August 1, 2010 at 1:03 pm
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.
August 1, 2010 at 2:26 pm
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. 🙂
August 1, 2010 at 7:47 pm
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 ! 😛
August 2, 2010 at 2:20 am
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
August 2, 2010 at 3:31 am
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: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
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
August 2, 2010 at 7:09 am
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.
August 2, 2010 at 8:13 am
Relational databases aren't supposed to be "simple" minded;
The overwhelming cost of a database application usually turns out to be the cost of training, the cost of integrating the data with the rest of the enterprise, and the cost of maintaining the system. Saving the cost of the actual database system turns out to be an irrelevance. Some of the most expensive database systems I've come across have been intended as the 'cheapest'. There are good reasons for choosing a Cloud solution but saving costs isn't necessarily one of them
Best wishes,
Phil Factor
August 9, 2010 at 2:44 am
Microsoft ruined their one decent database design tool when they bought out Visio - it was great before they got their mitts on it especially for object role modelling design and then they seemed to deprecate this and removed the "create database from model" facility. I still have Visio 2000 around because it worked.
August 17, 2010 at 3:12 pm
< sigh > I miss create from model....
August 17, 2010 at 3:37 pm
rbalmf (8/1/2010)
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. 🙂
Nice troll, I give it an 8.
August 17, 2010 at 5:01 pm
Phil Factor (8/2/2010)
Relational databases aren't supposed to be "simple" minded;
The overwhelming cost of a database application usually turns out to be the cost of training, the cost of integrating the data with the rest of the enterprise, and the cost of maintaining the system.
(This thread did a Lazarus today, so I'll contribute again.) That's the latest craze, Enterprise Master Data Management. Pays real good, too; from what I hear.
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply