Whats interesting to me about all this is the description of Workdays application architecture:

Workday runs on an in-memory database [...] it uses a relational database (mySQL) only for persistence [...]. This persistent database has exactly three tables, one for data, one for metadata, and one for instructions. Yes, that’s right. All data–the employees, the positions, the organizational structure, and even the layout of a screen–is stored in the same table. – From: Workday: Forget ERP, start over

I wonder how this compares to Xero’s architecture. Knowing Craig Walker – I’d be surprised to here there wasn’t at least some meta-modelling in Xero.
It seems like the traditional relational/OLTP approach of having strictly defined, highly normalised schemas which you hydrate/dehydrate into runtime objects is losing currency. Pat Helland – Jim Gray’s protege – is back at Microsoft and preaching heresy about traditional views around OLTP. Here’s some of his recent stuff that’s got me thinking:

• Life Beyond Distributed Transactions: an Apostate’s Opinion
• Accountants Don’t Use Erasers
• Normalization Is for Sissies

It seems like the more I think about this – the more this seems like the future. Here’s some other stuff I’ve read recently along similar lines:

• One Size Fits All: An Idea whose Time has Come and Gone
• Joe Gregorio’s Mega data post
• Scaling from 0 to 40 hits per second in 3 days

More Info at:

• The end of ERP?
• Workday unveils Financials and Work Tags

My question at the time was – what would be the use of a cross join in a practical system? In my time I’ve occasionally run a cross join by accident (forgetting a where clause or screwing up the join condition) – sometimes even on production systems with very large databases – whoops!

Today – I finally got to use one to solve a business problem! Here’s the scenario (bad are words censored):

bad_words         comments

+---------------+ +-------+------------+------+
| word          | | id    | comments   | live |
+---------------+ +-------+------------+------+
| W*NK*RS       | |     1 | a comm...  |    1 |
| B*ST*RDS      | |     2 | another... |    1 |
| ARS*          | | 36000 | lots...    |    1 |
| M*TH*RF*CK*RS | +-------+------------+------+
| C*NTS         |    36,000 rows
| C*CKS         |
| etc.          |
+---------------+
  648 rows

Two tables – one with a list of words which should not appear in the other table. The table to be scanned actually has three columns which need to be checked.

What I did was cross join both tables (resulting in 23,328,000 rows) and then use the where clause to filter the out the rows which don’t contain at least one bad word.

INSERT INTO bad
SELECT DISTINCT c.id
FROM comments c, bad_words w
WHERE
pros LIKE CONCAT('%',w.word,'%')
OR cons LIKE CONCAT('%',w.word,'%')
OR comments LIKE CONCAT('%',w.word,'%')

Note: It actually got more complicated than this – we needed to match on word boundaries – which meant using a regex – but the principle was the same.

1. This was impressive on a number of levels – state of the art for DOS was dbaseIII which didn’t support SQL but had some twisted language all it’s own.