After having a go at the information on the Entity Framework and other ADO.NET 3.0 papers that were posted about a month ago, I was trying to come up with a good example of relational tables or views that are designed with entities in mind. Or perhaps from entities. Concepts like inheritence, for example. Unlike my good friend Ted Neward, I'm not about to make a blanket statement like "entities good" or "entities bad" (I believe Ted has a Political Science degree of some sort in his background), just looking for examples of an entity based design "in nature".

Then, someone sent me, out of the blue, a request for a diagram of the new system metadata views in SQL Server 2005. There's a PDF of a E/R diagram for them out on the web, and the more I looked at it, the more "interesting" the design looked. I happen to be doing some work with the system views for an upcoming paper, and came across the word "inherited" in SQL Server Books online description of them. Here's some excerpts:

-For a list of columns that this view inherits, see sys.objects (Transact-SQL).

-<inherited columns> - inherits from sys.xml_schema_components

-Some catalog views inherit rows from other catalog views. For example, the sys.tables catalog view inherits from the sys.objects catalog view. The sys.objects catalog view is referred to as the base view, and the sys.tables view is called the derived view. [base view and derived view? really?]  

-This can be summarized as follows:

-The base view contains a subset of columns and a superset of rows. The derived view contains a superset of columns and a subset of rows.

It's almost as though some of these follow one of the traditional patterns for mapping object/entity models to relational. But I'll leave this to you to decide. Entities are never a subject without controversy.

I wonder how I'd query these in EntitySQL. Or DLINQ.

Even now, although SQL Server 2005 has been for about 3/4 of a year, when I teach people about the new developer features, I'm still asked about the zen of the new features. Do they follow a common theme? Is there a usage pattern that emcompasses all of the things like Service Broker, SQLCLR, XML data type and query, Query Notifications, Event Notifications, HTTP Endpoints?

Here's an academic paper by Dave Campbell that explains at least one usage: towards a Service-Oriented, Active database. This paper, released in 2005, ties together most of it.

I've been just pointing out the paper when folks ask me the "why" question for some time now. Making a database Service and asynchrony-capable is one of the ways to build a scale-out solution. I'll never have to ask "what happened to my application state when [mid-tier host of choice here] was temporarily offline" again.

If you hadn't noticed, I've stopped taking comments and trackbacks for a while. I figured if you'all like video poker, you know where to find it. I'll try and put them back soon, because you and I lose the valuable feedback along with the valueless drivel. For example...

I'd mentioned in yesterday's blog entry about scale out being a "last resort". Today, someone from a consultancy/solution design group at Microsoft said "but we don't recommend scale-out only as a last resort any more." The new database technology features along with advances in hardware make it accessible to all.

All? So there you have it. I'm used to thinking in terms of buying myself a 1gig or more personal music player to replace the 64meg one I bought last year. For the same price or less. But the commoditization of once high-end only software solution designs? Or approachable (to all) incremental design evolution towards the high-end without a major rewrite? Hmmm...

Good. I was having trouble figuring out how to max out the database system from the design meeting room, anyway.

Reading some papers on scale-out, I came across this in the SQL Server 2000 resource kit: "Scaling up is the first approach you should consider, ... scaling out should be the final consideration." Other papers mention "in order to best implement a scale-up architecture, it has to be planned in advance." and "it is easier to add scale-out and partitioning to an application designed with partitioning in mind". Hmmm... 

These statements seemed to be in opposition (at least to me). And then I ran them past Mary (who is back to being part-time DBA, but working from home) and she came up with:

"I've yet to see an architect who can max out a database box from the confines of the meeting room during a design meeting."

Great. The picture of this meeting in my head just cracked me up. "It's like, that insurance you never know you need until you really need it."

BTW, SQL Server 2005 has some scale-out features, SQL Server 2000 didn't have. And allows scaling-out in stages, one service at a time, if you want.

A few weeks ago, I told you about Elizabeth Vitt joining us at SQLskills. She's also be bitten by the blogging bug and is blogging now. Liz is a Business Intelligence specialist and author. Her lately paper "Integration Services: Performance Tuning Techniques" is out on Microsoft Technet, this week. Check out her latest blog entry on Influencing Aggregation Candidates. And, oh yes, she'll be doing (what else) the Business Intellegence track of our Immersion series, beginning with a day of “Exploring the Power of Business Intelligence” in Chicago.

At TechEd, a couple of folks came up to me and asked "we see around at conferences and read your blog, but when are you going to offer any...ahem... *public* classes, already?" I see you were a "special guest" at a training event back in March, but we couldn't afford to go to Amsterdam. Well...SQLskills will be giving a series of public training events starting in July. I'm participating in the Chicago and New York city events, and a 1-day'er in Reading. And we're scheduling 2007. Check it out on the website. We enabled signup on the website just recently. And there are specials.

My topic/track for the event is "Building Scale-Out Applications with SQL Server 2005". Reason for the sudden focus on ends (apps) rather than means (features) is the revelation that all the "nice features" of SQL Server, that is T-SQL enhancements, SQLCLR, and XML are really "enabling technologies" for scale out applications that can handle all types of data.

If you liked these as nice features in a vacuum, they're even better when implemented in concert. The glue that ties all these together is the Service Broker feature. In conjunction with replication and distributed query/transactions (used sparingly), scale-out requires (cries out for) asynchrony and data-directed routing (aka data-dependent routing) and this is where broker comes in.

But isn't broker only between SQL Servers? That's where using SQL Server's HTTP endpoint as a gateway comes in. But, we won't forget the XML data type and queries, SQLCLR, T-SQL, or related technologies. After all, your service has to do something besides add 2 numbers together. And it must be fast, in messages/sec.

The other thing that's exciting about the SQLskills immersion idea (see Kim's blog post) is that we invite folks to "bring their own problem". That's cool, as a consultant, I'm always the one who "makes things work". That's (making things work) is part of what I've been doing lately. Mostly, I took I year-long "hiatus" from public classes; my last official class for [previous company] was July 2005. For the two years before July 2005, I was mostly "Mr Yukon Ascend", not a lot of public there either. Since August 2005, I've worked on SQL Server 2005 launch, finished the book, and did a few private offerings. Not exactly retirement, but...

Hiatus over.