Blog Aggregator - Amardeep Sidhu

Next Thursday, May 8, the New England SQL Server Users Group will have a special meeting, featuring Craig Freedman from the SQL Server development team.  Craig is The Man when it comes to query optimizer internals, and wrote an incredibly detailed chapter on the topic for “Inside SQL Server 2005: Query Tuning and Optimization”.
At the […]

Brian Tkatch has launched a thread on the PL/SQL forum about enhancements to SQL which would just basically save some typing: Things i wish SQL supported. The lazy man’s list. This is quite a revealing thread, because it is always interesting to see what shortcuts people would like to take. It’s a bit like peeking inside the medicine cabinet in other people’s bathrooms (not that I would ever do that).

My personal wish is for:

select * {-empno} from emp;

That is, select all columns from the EMP table except EMPNO. This would be particularly useful for querying tables with BLOB columns in SQL*Plus.

As the thread as grown it has turned into a discussion of SQL theory (”conceptually, (using Venn diagrams) the tables/views are the circles, and the predicates define in what way the circles overlap”) which requires too much concentration. The thread was supposed to be about laziness!

The patron saint of programmer laziness is Larry Wall, the inventor of Perl:

“The virtues extolled for Perl programmers are laziness, impatience, and hubris. Together, these admirable characteristics have led to the creation and use of many publicly accessible Perl modules. Because of laziness, programmers would rather write modules than repeat a procedure over and over (and would rather use modules written by other people than write new code from scratch). Because of impatience, programmers write consolidated code that is flexible enough to anticipate their future needs. And because of hubris, programmers share their triumphs with the rest of the Perl community and continually tweak their modules until they’re the best they can be.”

The problem with proactive laziness is that it can be hard to estimate how much effort will be saved later by putting in some extra effort now. Plus, writing automating utilities and code generators can just be a seductive form of procrastination. It feels like work but we aren’t moving forwards. In the end we spend so much time sharpening the axe that we never get around to cutting down the tree. So the trick is to only automate the things we know it will be worth automating. This means doing something the plain way at first. Only when we get to the second or third cut’n'paste should we consider whether we need a parameterised module instead. The important thing is to automate early, in order to derive the maximum return on the work.

I am currently practicing cut’n'paste programming in a test data generator. I could refactor my code to drive off an array but re-editing my package to populate a collection will be a PITA. I should have done it some time ago, but I failed to realise just how many additional datasets I was going to need. At this point the ROI on the automation is quite small. So I have chosen to continue paying the find/copy/edit tax rather than spending half a day to figure out a better way of doing things. In the long run I will have expended more effort but in the meantime I keep making progress towards the main goal.

The 95th edition of Log Buffer, the weekly review of database blogs, has been published by Mark Schoonover on his Mark’s IT Blog.
We can look forward to LB#98 Jeff Smith’s Jeff’s SQL Server Blog on May 23rd. There’s always plenty of room for more editors, so don’t waste another minute — send an […]

Thought I might share some thoughts regarding recoverability issues with regard to having indexes separate and stored in their own tablespace.
I’ve already discussed here how the loss of an index only tablespace would be a catastrophic event, with the database in dire straights until the indexes are recovered. Therefore the faster we can recover from the […]

I’ve written several notes about hinting, such as:

Hints again: do you know what they really mean.
Ignoring hints: new DDL makes old hints “ignorable”.
Full HInting: the difficulty of getting it right.
qb_name: a really important hint introduced in 10g
push_subq: how upgrades can stop hints working.

In fact, by using at the “Select Category” list to the right, I […]

Yes I got back today morning from a 8 day program. I was supposed to be spending just 4 days and was going to leave on the last Sunday only. But all of a sudden , last Wednesday I received a call from the India core delivery manager that there was a program which was […]

What is daughter card in blade world?

A printed circuit board that plugs into another circuit board (usually the motherboard). A daughtercard (adapter card) is similar to an expansion board, but it accesses the motherboard components (memory and CPU) directly instead of sending data through the slower expansion bus.

A daughter card is also called a daughterboard.

Why daughter cards are introduced in blade server world?

IBM® and Intel® have developed the Blade Open Specification (BOS) to enable companies to develop and build compatible switch modules, blade daughter cards (adapter cards), and appliance and communications blades. Hardware developers can now more easily develop and build compatible blade products in these categories and participate in the rapidly growing blades marketplace served by the IBM BladeCenter and the Intel Enterprise Blade Server platforms. Through the release of the design specification, we can harness the development power of the industry and deliver a more comprehensive solution roadmap for our diverse customer base.