(I also commented on the article, but nobody seems to be commenting over there, so reposting...)<p>The advantage of statically typed RDBMS that he's leaving out here are (a) storage optimization (b) query optimization (as jawngee has already noted).<p>You could get halfway to simulating a dynamically-typed RDBMS by declaring all your columns as, say, VARCHAR(5000). You could store strings, integers, floats, dates, etc. all in there pretty simply. However, they would use a lot more storage space as strings than they would as native data types (e.g. integer 1000 is one byte, string '1000' is 4). Over a large data set that would really add up.<p>Secondly, when doing queries, your comparison operators (e.g. WHERE date > 2009-07-06) would be way less efficient as string comparisons than native type comparisons.<p>I don't want to be dismissive and curmudgeonly about this, but over and over what I hear from people enthusiastic about NoSQL solutions is that they solve the current problems of RDBMS, while forgetting all the great features that we have spent the last 30 years building <i>into</i> database systems.<p>The current "limitations" of SQL-based systems are often in fact age-old trade-offs that we made, but people have forgotten the positive benefits of those trade-offs. The reason databases are statically typed is because that saves storage space and processing time. The reason there's a standardized, domain-specific language that you have to learn is because having to learn a completely new API and mental model every time you want to access a data store from a new vendor is inefficient. Oh, and the reason SQL is so complicated is because <i>relational algebra is complicated</i>.<p>Sure, SQL and RDBMS have their limitations. They're not the right tool for every job, and they are not even 100% perfect at the jobs where they are the right tool. But too often I hear people saying "fuck SQL!" simply because they don't want to learn it, and because they're too early on in their little pet project to realize the scalability problems a NoSQL system is going to run into that RDBMS solved 20+ years ago.
<sarcasm>
Yeah that would be totally awesome! Now our databases can't optimize our query plans and any aggregate functions will be doing super cheap type conversions between strings and number types!<p>And, really, who cares about data consistency? Sure that stupid little script is inserting strings into what should be a numeric column, but I'm sure that won't cause any problems at all when the monthly reports run, or the batch processes that charge our customers run, because the database will know how to handle such cases because the DB developers have written all that extra logic in it for such cases.
</sarcasm><p><reality>
Stop being lazy.
</reality>
<i>even with a statically typed database, type matching errors storing data are only reported at runtime! (That is, our java compiler doesn’t check our MySQL schema.)</i><p>That isn't necessary the case: for example, PG'Ocaml allows Ocaml programs that access a PostgreSQL database to have their type consistency checked at compile-time.<p><a href="http://developer.berlios.de/projects/pgocaml/" rel="nofollow">http://developer.berlios.de/projects/pgocaml/</a>
How does he get from the the text of the article, which approximately says "It would be useful in some cases for a database to be dynamically typed" to the sweeping statement "Databases Should be Dynamically Typed".<p>As others have noted, relational databases have a rigorous theoretical foundation that is not consistent with what he describes as dynamic typing. He should consider looking at a graph database. Many of these are billed as "RDF Stores" or "Triple Stores". Franz's AllegroGraph is an excellent example.
One situation that calls for a typeless database is when the system <i>must</i> accept data from a source that's unwilling or unable to adhere to a well-defined static schema.