There appear to be four responses. Two were numbered, the third is a rambling thought on scalability, and the fourth is a thought on management's discomfort with the truth.

Physical Tuning.

"...databases can be tuned by creating appropriate indexes, removing others, modifying the physical database schema to suit the most common types of queries, etc. So it isn't clear whether the PL/SQL figure could be better if the database was optimised by a good DBA."

While a good …

While the question of speed came up recently, it ties in to a long-standing position of mine. I ran some realistic benchmarks, and I'm much happier with my architecture now.

Background.

Years ago, at a Siebel conference, I heard a heretical comment. Specifically, they use the RDBMS as simple, flat …

Here are some useful quotes:

• Andrew’s first law of career spotting: Accountants are people who, when confronted with a problem, think “I know, I’ll use [A spreadsheet]”. Now they have two problems.
• [A spreadsheet] is a great prototyping tool, just don’t let it anywhere near your production …

If we look at a spreadsheet as a document we can develop a parser that locates the user-supplied information in that document. Like any language, we'll have to treat some elements of the spreadsheet as pure syntax, little more than punctuation. In the case of embedded formulas, these are elaborate …

See "When a Column is Not a Column " for a rant on failed attempts to scale spreadsheets up into relational databases. Bottom Line: A spreadsheet column is rarely an RDBMS column. Often the SS column's label is a key value, just like the SS row's label, and the cell's value …

I'm very excited to be giving a presentation at PyCon '07. A 30-minute slot is tough because the Star Schema can be confusing. The coding is pretty transparent (IMO), but the background for why I had to do this and places where it can be used are more interesting than …

First, see "OSCON - Open Data " by Tim Bray, then see "Set My Data Free " in Kontrawize.

Here are some quotes "At the end of the day, information outlives software and transcends software and is more valuable than software." "Data matters. It shouldn't be an afterthought. It will outlive your applications …

First, let's pick the conclusion out of the middle: "However, the computation for the first and last business day of the month is trivial. So, just codify this."

Since we still lack any usable context, we're struggling with the definition of basic terms. Is this the calendar month, or the …

Here's the example:

"I need to calculate first 'business day' of the month. Last 'business day', too."

Note that the problem which this solves is unstated. Why does anyone need to "calculate" this?

Here's a single tidbit of technical context, not useful really, but all I know: it's a polyglot …