February 2008 - Posts
There are new TPC-E benchmarks available for SQL Server 2008. And it's not even out!!!!
The 3rd place, the IBM entry, is the interesting one. Less CPUs and cores and getting close to the second place entry.
I'm not sure what these benchmarks mean, especially the new TPC-E one, but it's an interesting comparative look at different systems.
The launch event is tomorrow in LA and I'm not going, and find myself a little disappointed. There will be a Denver event on Mar 20 and I'm planning on going, but with kids out of school, we'll have to see how that goes with my wife.
I think it's a good thing to be able to attend a marketing event like this, and make no mistake, this is a marketing event. Conferences, I think, are split between marketing and good information, but in this case, as with many of the launches I've attended (Windows 95, Windows 2000, SQL Server 2005, Windows XP), this is put on by the marketing group.
Which means that they want your contact information and hope to try and influence you to buy more of their (in this case Microsoft's) products. Or they want you to influence your boss. That's a lot of what is happening here where the sponsors are trying to get you to view them positively and spend more, or maybe not spend less.
In return, at least in the US, you get T-shirts and other swag, free food, maybe other goodies. What's amazing is how much goodwill the swag brings. You might think you're immune, but you're not. You definitely view them a little better when getting free stuff, and as much as I wish it wasn't so, I'll admit it happens.
So why go?
This is in tomorrow's editorial, but you should go to learn a bit, network with people, get ideas, but mostly to recharge. Get out of the office, think about the technology and get more excited about the technology in a new environment. It's a cheap way to build goodwill, and if you have to, give that as the reason to your boss. If there's nothing pressing, and more often than not there's nothing that can't wait a day, get out of the office, get a shirt, meet some colleagues, and remember how much fun technology can be.
It isn't often that I see what the real advantages are, and I've been doing it so long that I almost take it for granted, but here's a look at my last 12 hours.
- Tosing and turning in bed, sore back, alternating between chills and sweating as a fever came and went.
- Up around 4 for a hot shower and aspirin to ease my aching back.
- Up late to help get the kids ready, so they missed the bus. So my wife drove them.
- Checking on email before feelng dizzy and going back to bed (7:30ish)
- Waking up to hear the phone ringing and realizing I had a Performance review set for this morning.
- Running to get the phone and then back to bed to wait for a call back.
- Doing the review on the phone, getting chills near the ned.
- Sleeping for about 4 more hours, and back in the sweating, fever broken phase.
With a traditional job, this would have been possibly a hassle, with me being late after taking the kids (or my wife) and probably a sick day. Since I'm the guy that does the main work here on the site, that could be an issue. And with daily work done, I'm glad that I'm actually ahead of the game with podcasts edited and uploaded through Tuesday.
So I'm between fevers, hopefully done, and able to check a little email, handle a few things, and hopefully better quicker by remaining close to bed and away from other people.
I've been calling for Service Pack 3 and I've been debating the need, the criticality, and even the problems with the process. There's been an interesting debate with people both at SQLServerCentral.com, internal Microsoft people I know, and in the MVP forums. What's amazing to me is how many people seem to think that this is critical and from their dialog, they feel that SQL Server 2005 is garbage without it.
I'm not sure I'm even close to feeling that way.
My feeling is that SQL Server 2005 is a very stable release. There might be some problems, but I've heard so much praise from people over the last two years, so many advantages and positive stories that I know it's working. I know that people are using it and it's working well in production. I doubted that it was adopted by many people, but all the surveys I've seen and run say that there are significant numbers of people using it.
So for the experts, the MVPs, the consultants, which is it? If it's working and you've gotten workarounds can it be that bad? There might be issues in places, but I've just seen too many people sing the praises for me to think that it's that bad. As embaressing as the bugs are, I'm not sure that they are that many critical ones.
I get a bit of a delay in working on the set down in the basement thanks to the weather. It was beautiful today, nearly 60F and without much wind, so I did my semi-weekly podcast work outside, getting 4 done today that I'd previously written.
Hopefully the wind wasn't too bad. It came up a few times and we had some nice delays while airplanes and other vehicles interupted the shooting.
Some see this as a misnomer, or even an oxymoron. Many countries don't allow "engineer" to be a title for software because it's not regulated like engineering is. Some think it's a joke, given the state of software development, the constant missed schedules and problems.
Buck Woody wrote an interesting blog post about this and how it might make more sense to view software engineering as a manufacturing process as opposed to engineering. After all, we build things, worry about QC, QA, etc.
I used to feel that other engineering professions were more stable, more successful, and delivered projects closer to on time, on budget, and within estimates. And to a large extent I think they might be more succesful, but I think they suffer from quite a few errors in their own projects. And they operate in a much more constricted environment. They work in an area where they can calculate how things work, more of a science than the "artistic creations" of software.
Many engineering projects are one-off items. Building a bridge in Colorado isn't substantially different than building a bridge in Washington state. However it is different and engineers must make allowances for different codes, different materials, fundamental differences in how things are done and the conditions that must be withstood.
It's only natural that we make comparisons between professions. And while manufacturing and engineering deal with different resources, I'm not sure that it's that much different. We deal with the human elements, varying levels of productivty, even with one resource, and constantly shifting requirements. Engineers have different requirements and must work with different supplies and depend on various resources, similar isues with manufacturing, and perhaps that all balances out. After all I think in many cases the software resources enjoy their jobs much more than the other resources.
However software in many cases has a very different requirement. Our software must often run in many, many environments, something that isn't the case with many engineering or manufacturing products. Most products, even military and industrial strength products are designed to work within a band of conditions. And they're often not warrantied outside that band. Software runs in an incredible range of environments, even sometimes in those controlled, corporate environments.
When I really think about it, I'm not sure that any of these analogies is that good. Most engineers or manufacturers can calculate how things will behave and they can draw on the physical characteristics of the materials with which they work. Even new materials will be tested to ensure that their limits and ranges can be known. In the digital world that's not the case. We constantly work in new areas, assembling things whose behavior cannot be that well known because of the millions of possibly branches, inputs, and outputs that our work can be subjected to.
In the end I think software is unlike any other process of building, especially in one key area. It's maturity is much lower than any of those others.
Someone sent me this note about a talk they'd had at their user group and the guest speaker mentioned the following:
- -SQL
is not based on “computer science”. He challenged us to come up with a
“computer science” term to define a database table. No one could to his
satisfaction.
- -No
current SQL product truly implements the “relational model” (except of course
for the one he just wrote, which isn’t commercially available).
- -Microsoft
is making a major push to declarative modeling languages, the object model, and
the entity framework. SQL doesn’t fit in here anywhere.
- -.NET
developers hate coding in SQL and despise stored procedures. They can’t define
a SQL table as a .NET variable.
- -The
war inside Microsoft is already over. A few years back everyone on the
SQL Server development team who supported the relational model were removed and
replaced by .NET folks.
- -LINC
is the reason the 2008 product is late, and is the first step towards .NET
transparency for data stores.
- -SQL
Server as a product is already dead inside Microsoft, and SQL Server DBAs are
going to become extinct, since .NET, object-oriented developers will be able to
create and maintain their own data stores.
Personally I think it's crap. Or most of it.
There is a push to do more LINQ and get it deployed. That's because it makes developers more productive quicker and they don't have to learn SQL, which many of them don't, and many more do poorly. There are exceptions, but as a general rule I think that most developers don't get the SET model of data.
However there are quite a few DBAs on the SQL Server team. I know a few of them personally and they are recent hires, so there isn't a push to just get .NET people up there. That being said, there's a lot of .NET code inside SQL Server and they're using it to extend the system with things like the HierarchyID, spatial work, etc. Plus it's a software product that needs to be coded.
SQL isn't going away. As a data store, it handles and processes more data than any developer will deal with in their own data store. There are all sorts of large amounts of data, backup, recovery, and more that require a strong back end database to manage. A data store just won't cut it. And relational design will still be required for warehousing, BI, and many other applications. The developer view just isn't practical.
That's not to say SQL is compliant. No one is to my knowledge and it doesn't stop those products from working. SQL Server is a variant, and the finest one, IMHO.
I started working through some labs for my SQL Server 2008 class and one of the labs was on the new Change Data Capture, essentially an auditing action that allows you to tell what changes have been made to data in a table, including insertions and deletions. You have to enable the option for each table, but it proves to be very interesting.
It uses LSN from the log, which there are functions to allow you to grab based on times, and so I wondered if it was a view into the log. This makes some sense, but since you backup and truncate the log, your auditing would be compromised. Or your log could grow out of control.
Essentially you set upa retention schedule and this allows you to manage how long you keep data around. I have to dig in more, but this looks like a very interesting feature. What I'm not sure is how well it will be used and if it will become a management headache for administrators. And you can backup and restore audit data?
Actually more it's "our way" as mentioned in Andy's post, and less my way than by committee these days with Red Gate and a few other people helping run the show here at SQLServerCentral.
That was a fundamental decision that we made early on in this business to do things our way. We had offers to changes the way we did things, and we've had more than a few arguements about what our way should be, but it's always come down to a simple question: Is this how we'd want to be treated. And while we might have bent the borders around that at times, we've never, at least to my knowledge, done something that we agnozied about or lost sleep over.
I think that it's good advice to really think through the way you'd like your life to be run, your career, etc. and decide what basic principles you'd follow. Then stick to them. Knowing who you are and what you stand for goes a long way towards ensuring you are well grounded and will succeed. Success being defined to you and you alone.
Windows 2008 RTM'd this week, which means that in a few weeks, at the February Launch event, there will be two products that are shipping and have RTM'd, leaving only SQL Server 2008 as a product that's not yet finished. And likely won't be for 6 months.
Some people have wondered why I'm harping on this. After all, I was the one complaining fairly loudly about the 3 year cycle for database products. I'm not complaining it's been delayed. I think it's a good thing if two things happen:
1. Support for SQL Server 2000 gets extended
2. It gets removed from this launch event and gets it's own event later in the year, maybe at the PDC.
My complaint is that this is almost like vaporware. A fully feature complete CTP is supposed to be released, but who knows what will change before RTM. There are potentially new things coming in this CTP, which means they'll get large scale testing for the first time. Which means they might not be done in time for RTM, which I'm sure will be this year. Which means they could be vaporware!
My complaint is with the marketing side of things. They are giving SQL Server a bad name, which annoys me since I try hard to advocate it every day.