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 …

The "correct" answer is to fully normalize the design and get away from a mixed bag of columns and nulls. The MESS is bad from every perspective, except query performance. A semi-normalized design that separates the STATE CHANGES from the ESSENTIAL DEFINITION is an optimal design in many respects.

Here …

Experimental results depend on details of the database server and the data model used. Actual application software may have other confounding problems that make these results less dramatic or more dramatic when applied to a existing application design.

I compared three table designs described in a previous posting Normalization Experiment …

Fragmentation & similar is sometimes a storage problem in I/O generated, vs. the gross space consumed. This distinction didn't leap out at me.

Performance degradation and storage expansion are closely related, but only for certain kinds of queries. Full table scans are penalized by sparsely used storage. Individual row retrievals …