Some databases limit the size of text and/or varchar data, so that rows have a limited size. Sybase, for example, used to have a 255 character limit in varchars, and a 2048 byte limit for row size (off the top of my head, details may be wrong.) To store any text larger than 255 characters, the data was effectively stored offline from the row, in a special table, with a reference to the large text in the row.

DB2 also has row size limits, rows not being able to be bigger than ~0.5 the tablespace page size, so this can also require text to be stored offline in LOB tables.

I was talking about a table index. As in:
CREATE INDEX foo_idx ON foo(textfield);

This is not the same as a full text index, which generally stores an index row for each distinct word in the source row.

Foreign keys are good, but type independent. You just want to check that some foreign key actually references valid data in another table. If they match, they match.

However, typing in SQL is almost certainly a case of implementation details leaking through the abstraction layer. The data type is defined by the data and how it is used. Traditional SQL databases require that type data up front so they can organise the data on disk. But you shouldn't care how data is organised on disk.

When comparing dates, the data type is implicitly some form of timestamp. Whether that is stored on disk as a string with a "YYYY-MM-DD HH:SS" format, or as a UTC integer offset from 1970-01-01 00:00, it doesn't matter. Using the SQLite way, the two can be transparently stored and compared. There are probably better examples, like not having to declare varchar sizes versus text versus CLOB versus BLOB. They're all stored and indexed and searchable in the same way (not that you'd want to index any sort of LOB.)

And if you don't like it, just declare the types of the columns up front, and SQLite will use type affinity to convert the data for storage.

Personally, I like the optional typing in SQLite.

We can do, but people (even rocket scientists!) still get it wrong: http://en.wikipedia.org/wiki/Mars_Climate_Orbiter

Technical issues should use SI units.

Unless it's charged at night when there is a surplus of generation capacity.

In case you're not joking:
http://en.wikipedia.org/wiki/CE_mark

FLASH does (should) indeed fail gracefully. Once a block wears out, programming it will fail, and the FLASH and controller will know this and mark it bad. But other blocks will still be readable, and the now dead block contained no useful data (else the controller wouldn't be erasing it.)

What you're talking about are firmware based bugs, the controller not making the FLASH contents accessible. These problems are probably the result of block translation tables being corrupted, and is entirely the fault of the controller and firmware (not the FLASH.)

Certainly hybrid storage gives the best of both worlds. Using an SSD as a short term cache, that can be discarded if necessary is certainly one way to go.

But I no more trust a mechanical HD than FLASH to keep my data safe in the short/medium term. And HD can have firmware issues too.

FWIW, almost all my machines at home have SDD in one form or another, from a lowly Acer Aspire One netbook (8GB SSD - very crappy!) up to my work laptop with 80GB Intel G1 SSD. I've not yet lost data as a result of hardware failure over the two years I've had the various drives. Of course, a very small sample size.

Oh god, does this mean Apple have a patent on it?

Probably more to do with Nairobi's elevation. Nairobi is quite a way above sea level, the air thinner, and therefore not retaining as much heat as at sea level. But as solar cells or solar heating devices rely on solar radiation, rather than the resulting ambient heat, solar devices would be very effective nonetheless.

Would the world have the balls to hold the US to account on that, I wonder?

Like girls?