The Full Potential of SQL 2000

Question

The Full Potential of SQL 2000

Viewing 7 posts - 31 through 36 (of 36 total)

You must be logged in to reply to this topic. Login to reply

Jeff Moden SSC Guru Points: 1003865 More actions · Answer 1

Lynn Pettis (12/17/2008)
Co-worker at my previous employer really like Power Basic. Creates extremely fast and tight code. They recently added a /bloat switch that makes the executable bigger, but still runs as fast.

Man, I LOVED Power Basic... I actually started using it way back when it was called "Turbo Basic". Bob Zale and his crew did a really nice job.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Lynn Pettis SSC Guru Points: 442467 More actions · Answer 2

Well, it is still alive and kicking. My co-worker was taking a C class in college, wrote his programs using Power Basic first and got it working, then ported the code to C.

sausage.dog SSC Rookie Points: 31 More actions · Answer 3

Jeff Moden (12/17/2008)
rog pike (12/17/2008)
The great silicon dividend has been wasted. How can anyone gloat over all the bloat
Heh... man, do I agree with that! How many times have we heard "upgrade the hardware" as the fix for slow code? The only good part about the bloat is that incredibly large and fast harddisks and gobs of memory have become relatively inexpensive.

People scoff at the idea of buying bigger hardware but as you point out it's cheap. Oftentimes it's far cheaper than paying a team to optimise (read: rewrite) large chunks of an application. And as cloud computing becomes more prevalent with on-demand resources, low level optimisation makes even less sense. Naturally the system must run cost-effectively, but business will always balk at paying extra to reduce wait time for staff. Anything that actually requires someone to wait for more than 5 minutes is likely to be batch anyhow so the slow performance can often cost very little in real world terms.

Highly interactive systems need to be reponsive. That's a no brainer. But it's also something you're likely to catch in development if not UAT. If you have a serious userbase load testing should always be on the agenda.

RBarryYoung SSC Guru Points: 143329 More actions · Answer 4

rog pike (12/17/2008)
The great silicon dividend has been wasted. How can anyone gloat over all the bloat:)

Actually, that is not what this paper says. In fact it give a very balanced presentation of that very issue and includes a strong case that Moore's dividend has been spent on the benefits of better "programming languages, models, architectures, and development practices, up through the user-visible behavior and functionality of software".

Edit: removed Steve Jones name, accidentally included in the quote.

[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung [font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]

Jeff Moden SSC Guru Points: 1003865 More actions · Answer 5

sausage.dog (12/17/2008)
People scoff at the idea of buying bigger hardware but as you point out it's cheap. Oftentimes it's far cheaper than paying a team to optimise (read: rewrite) large chunks of an application.

That's why I believe in writing the code with performance in mind the first time... people make the mistake of thinking faster hardware is going to make the code faster. It frequently doesn't or, if it does, it's only for a short time until the scale of the requirements catches back up to the IO bottleneck or the memory limitation. I've see it happen over and over. There's also the hidden cost of migrating the data, etc, over to the new server. Doesn't matter how good the machine is, something like a triangular join on large data sets is going to eat it for lunch.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Phil Factor SSC-Insane Points: 20244 More actions · Answer 6

I have continual grief from developers over the makeup of the Development Database Server.

The development server should be a slow stolid reliable old workhorse. Developers always want the very latest hardware and software. I'm for the oldest version one can get away with. That's usually 2005 nowadays since everyone needs Varchar(MAX). (although large systems are still being developed in SQL Server 2000!). I like to get old production servers when they are slung out. Big Compaqs with banks of lovely rustling SCSIs. They're perfect for development

Then you go into test and production with the latest stable version of everything.

If you develop on a slooooowwwww computer, with looooaaaads of data then you get to see the painful performance areas. and both test and production are a glorious and pleasant surprise.

It sounds unkind to developers to make them see the hourglass as a penance for their coding sins, but sure as hell it speeds up development.

Best wishes,
Phil Factor

Steve Jones - SSC Editor SSC Guru Points: 734459 More actions · Answer 7

I do agree with Jeff that you need to write good code, but you also want to not get too caught up in it. There's a point when you're wasting time, expensive developer time fixing things that could be handled with a little more hardware.

It's hard to judge when that is, but it's definitely there. The problem is most people give up too soon on writing good code, or they don't know how, and then they run out of hardware before the load is handled.