I think this is a great line of thinking, Linchi.  One caution is that we're not all at multi-national corporations where we can just abandon one vendor for another, or implement a completely new hardware infrastructure, or port all of our existing code to a new platform.  So the audience that can follow your advice is somewhat limited, by definition.  :-)

Linchi - I thought that was a really good post, and I agree with your observations. I think it's really helpful to watch what other vendors and the market in general is doing. You never know when Microsoft is going to pick up a trend or a piece of technology from another vendor and put it in one of their products.

Are you sure you want to leave yourself open to the charge of maturity?

Raising the issue of looking 'around' seems to run counter to prevailing

winds. It's bad enough there's a lack of desire to do this but even worse

is the shortsightedness of what's happening within MS. Hopefully people

will take your lead and realize you can walk and chew gum at the same time.

Take a bow:)

I'm not sure whether I should be suprised, disturbed, or complacent. But this morning, I was greeted

Great post!  As a heterogeneous DBA but a SQL Server specialist and evangelist, I feel that it's always enriching to know what the competition is doing.  Thanks for the insight,

-Kevin

First off, thank you for this valuable information. Second, pardon me for unceremoniously skipping from this topic of discussion to a slightly different one, though pretty close to the SQL business. I believe, you can recommend something to me and help me here as I am not a SQL guru. I have to run the databases here and no surprise, we've selected Microsoft SQL Server. I feel like it'll be much easier to get in it than in other DB engines for me. Correct me if I'm wrong. I started with SQL express - oh, I know you'll probably be laughing at this out loud but I mostly need SQL as an auxiliary solution for the other solutions we use for working with various tasks here. Well, some tools just store their data in SQL databases so I HAVE to have SQL servers here. After all I find it legally acceptable to store program data in SQL rather than say in a flat file. Applications today need to store a whole lot of data. Configuration data, user input data, communication data, some other specific data that you wouldn't have imagined it could exit. I don't know if I am right or wrong but I just think it makes sense storing program data in SQL if you have something to configure. We used a tool that had proprietary database engine implemented in it and it was bad experience. It worked poorly. So I thought it would be a good idea to implement something easy to use and fast to operate. SQL. However, that poses a new problem to solve. Once you have a database you have to backup it. The need to manage backups through scripts makes me cringe. Yeah I've learned some basic SQL commands like backup database blah blah with init, COMPRESSION. But now what? I am still confused. In fact I don't really want to dig deep into SQL as I'm afraid it would overkill for what I need. I want it to be as fast as it's technically possible. Ah, by the way, compression. Yeah, great thing. I noticed that it makes a serious impact not only on a effective storing but it also affects processing speeds. Almost every database that I tried to compress with SQL since I started with SQL 2008 was finishing its backup in less time when I had been applying compression. But then again it turned out to be a battle for time and ironically all the time I saved from compressing a database was spent then on making SQL scripts. Since I am new to SQL I have to compile my scripts from various available scripts and it takes a lot of time.  The cool thing is that I recently stumbled upon a tool called Litespeed, tried it and found it very interesting. Look, it has both management features and a plethora of settings for a backup. I haven't yet explored all its options but I those that I've tried were enough for me to enjoy it. I don't know how this was accomplished, but it turned out that it compressed those databases I had been working with much better than the results I got from running compression scripts with that SQL build that I've tested. What was really surprising to me was that it did not require me to install SQL server 2008. So I just decided to put it under a stress-test and set it to work with SQL Server 2005. I was easy to configure. It was almost like with SQL Server 2008 setup compared to SQL 2005. Or like Windows Server 2008 setup compared to Windows Server 2003 RTM setup (you know they've improved it in R2). So I managed to setup and configure it quicker than I  expected. That was the first thing that I liked there. Third, I heard like it's impossible to have a backup database compressed and encrypted in SQL. I believe that source was wrong. I think, they meant there that it's impossible to apply compression to an encrypted backup file. I think if you apply encryption to a compressed database this should work well. Correct me if I'm wrong. Anyway even if I am wrong, I'd say you are able to compress AND encrypt my database in Litespeed. It was a great surprise that I was able to save database backup on a remote share without needing to take another steps like I did it when I managed backup with Management Studio. I know there's also TO DISK=''\\*" in SQL but again it was unhandy for me to always change parameters.

By the way, I scanned the Lightspeeds website (ScriptLogic) and it seems they good with SQL technologies http://scriptlogic.com/products/litespeed/

Looks like their management tools use SQL pretty tightly. I saw something for managing security on SQL, something that looked awesome. I don't know. What do you think?

Thanks.