Frustration and joy - Microsoft's CTP in action

@Kevin Bailey

Under all the fluffy GUI shit is a very competent database. Very. I'm certain it's better than postgres, as I've seen what it can do.

That said, there is a whole load of shit on top to 'add value'. I suspect Mr. Whitehorn would have been better off starting from sql server 2000 and adding in his stuff.

I endorse the reaction of @Simon. What are you talking about re. 4gig limits? The limit on eg. MS windows 2000 is terabytes for files. For ram space you can go up to 64gig on old (32-bit) hardware with some tweaking, but you're using 64-bit aren't you so WTF?

And why worry about DB size? Overall size counts - total data doesn't get smaller if you store it outside the db; there's just as much to back up, only it's in pieces... which makes reliable backup during runs problematic, if a file is added/deleted while backup is going on.

Please explain!

Yay!

Badly patched Sybase reissue grinding along on a reworked GUI shell for a CP/M rip-off.

@Kevin Bailey

Think you'll find VS is the most popular IDE used.

And I think you'll also find that the LAMP stack in question isn't beta - it's a full release. This is a CTP.

The day a LAMP developer spouts how easy it is to setup their environment compared to a .Net is the day I move to <shudders> Mac OS X </shudders>

Oh, and out of curiosity, your telling me that you can install a web server, database and IDE with a single command...? Not specifying default passwords, components, locations and tools? In a single command?

And a final point Mr. LAMP lover - you can install the .Net environments (DB, IDE, reporting suites, Framework etc.) all via command line as well. Just most people prefer ease of use when installing a new technology that's currently unreleased rather than obsecure commands. Saves on the admin overhead when your TESTING BETA SOFTWARE

Jerk.

Must have been tough

@Jerk

Boy it must have been tough at school having a name like that!

VS most popular?

Probably not - just check out the number of jobs asking for PHP. And when has 'popular' equated to 'good'.

The install DOES work from a single command. Listen carefully because you may be close to enlightenment, grasshopper.

All packages install with sensible, secure defaults. All packages also install a README file which will explain clearly any further steps.

There - that's it. I've installed (L)AMP so many times I now even cut and paste the line from my notes.

What I suggest is find someone to show you. You'll be amazed how easy it is.

And being offensive is pretty small minded - but I suppose that explains why you can't learn anything.

password not needed

@Jerk

Just to explain one of the many things you don't know.

You CAN install a DB without setting a password.

For the Postgresql DB an admin user called postgres is set up during install. It is secure by default as you can not log in as this user.

To become this user you type

su - postgres

and then carry out commands such as createdb and create(db)user.

See, simple, easy and yet something else about which you know nothing. You have to LEARN stuff.

Then to create a DB you type

createdb

or to create a user you type

createuser

4GB Limit

OK, my bad.

The problem was my careless editing. This article was supposed to be 800 words long and my initial draft was over 1,200; so some serious surgery had to be performed. This section originally read as:

“As it happens, our application has a great number of BLOBs. In SQL Server 2005 we tried both approaches. Storage in the database rapidly produced databases files that exceeded the 4GB database file limit that was imposed because, just to get started, we were using SQL Server 2005 Express running on a 32 bit operating system. We did some further testing and tried storing the BLOBs in the file system. This was better but managing the pointers to ensure that the pointed to the correct BLOB - in our case by bar codes - was time consuming and limiting. So, when the CTP arrived we moved to 64 bit (as described in an earlier article) and started using the file streaming which has proved to be fabulous for our application.”

130 words – far too long. So I edited it down to this:

“As it happens, our application has a great number of BLOBs. In SQL Server 2005 we tried both approaches. Storage in the database rapidly produced databases files that exceeded the 4GB limit on a 32-bit operating system. Storing the BLOBs in the file system was better but managing the pointers to the correct BLOB - in our case by bar codes - was time consuming and limiting.

File streaming is fabulous for our application.”

Which is a much trimmer 74 words. Sadly I failed to notice that I had ended up implying that there is a 4 GByte limit on 32 bit OSs.

But..

But, SQL Server Express has a 4GB limit? Wow. I'm not used to using software with artificial limits placed on it.

@Mark Whitehorn

Thanks for explaining that. nonetheless you aren't half making a massive rod for your own back by beta testing for MS. Seriously, are you going to use the express version for your final deployment? If not, why are you having to deal with its limits? And why (oh why etc.) don't you take a stable DB (SQL server 2000/5 for example) and see if you can graft your geo stuff on top. There must be someone who sells these calculations in a library you can buy.

I hope you actually get something back from MS to repay you for all you're doing on their behalf. If they can't put together a decent beta install then they don't deserve beta testers at all.

Okay, here's a suggestion. Install 2000 or 2005, and 2008. Do all data storage etc on 2000/2005 and link to them via linked servers (whatever it's called) from 2008. The data looks local to '08; you just have to refer to the tables as

server.db.owner.table in your select statements. For flexibility you should define SPs or views to hide even this syntax.

*if* that works then you have the benefits of one with much less crap of the other, until MS ships a working '08.

I'm bored and I might be able to help. My email is <qqq.ppp2 (ta) gmail.cooom>, demunge the obvious.

Replies to several comments

@ bored AC

"Seriously, are you going to use the express version for your final deployment?"

"nonetheless you aren't half making a massive rod for your own back by beta testing for MS"

Thanks for the comments. No, we won’t be using the Express version – we were using that early on (in fact, in the 2005 version) to do some rough prototyping and it happened to illustrate rather elegantly that the database file size was getting quite large, even with relatively few blobs.

And no, I don’t think we are making rods for backs. The original decision to use the 2008 stack was made precisely so that we could gain experience with 2008. You will have gathered that the download/install of Microsoft CTPs does not fill me with awe and wonder (or, rather, it does, but only in a bad way….). However all of the rest of the CTP program, actually using the software has been, as reported in the rest of this series, remarkable pain free. We have gained huge experience and both the management and the developers are extremely happy that we decided to go down the CTP route.

Had we started with 2000/2005 as you suggest we wouldn’t have gained the experience.

@Kevin Bailey

Kevin asks an interesting question “Who pays for the install time?” The answer is the management. Are they happy to do so? They are delighted. Why? Because they understood at the time the decision was made that working with a CTP program has associated costs. They (not the developers) decided that the benefits were likely to outweigh the costs and, happily, in this case, they have been proved correct.

@AC (possibly the same one, possibly not, it’s difficult to tell…..)

“And why worry about DB size? Overall size counts - total data doesn't get smaller if you store it outside the db; there's just as much to back up, only it's in pieces... which makes reliable backup during runs problematic, if a file is added/deleted while backup is going on. Please explain!”

It’s always a trade off. Keeping the BLOBS in the file system can be an advantage if the blobs are mainly static and can be compartmentalised. That way you can only backup the new BLOBS and it makes the backup of the database much faster because it is smaller. However I don’t want to make it sound as if these were the only considerations. We could, for example, also have partitioned the database and achieved a similar (but not identical) effect. It is easy to see these architecture decisions as simple – in fact they are relatively complex and there was some discussion and testing before we made the decision. (Indeed, that is another reason why we wanted to use the CTP, so that we could do the testing!).

@Replies to several comments

Yep, same AC.

"That way you can only backup the new BLOBS and it makes the backup of the database much faster because it is smaller."

Or use a differential backup?

I dunno. you seem to have chosen the most rocky route up this mountain. I'll be watching your progress with interest.Best of luck.