prose :: and :: conz

Is database schema static typing for persistence?

I’ve heard it stated that a database schema is like static typing for your persistence. I’m still struggling to decide if I agree. On the surface it sounds true, but while I love static typing I really don’t like schemas.

I’ll start where I see that this is a true statement. Both types and database schema are declarative in nature. There isn’t logic per se. It simply states what must be true about the data prior to run time. They both inhibit non-conforming data from entering the system. Furthermore, the data types that you define in the application code essentially define a schema for your runtime data.

It’s no wonder someone thought that ORM was a great idea. You can have a database schema and the data schema in code. Then apply a little glue, and you’re rolling. Unfortunately, it tends to be fundamentally flawed for relational stores due to the impedance mismatch between objects and relational algebra. But I digress…

I also experience frustration with both. Recently I posted about how sometimes static typing does in fact suck (blogger’s note: after some very helpful comments, I was able to learn that it was the programmer that sucked. Follow-up post coming soon). The point here isn’t what can and cannot be done in schemas or static typing, but the amount of work it can require just to make the static checker or schema validator satisfied with your code. Even with nice features, it can take some work to express your domain in the respective declarative language.

The only thing I can think of that is different between static typing and databases with schema is when the data gets checked. In my experience, I’ve found most of my schema screw ups at run time. It wasn’t a problem with passing an integer when a string is expected. Even a crappy type system like Java along with Hibernate can help you there. It was always with the other constraints among the tables I was trying to manipulate in one request. I must admit that ultimately I think the schemas I’ve devised in the past have been far too complex. There is certainly some blame for those problems that belongs to me.

That isn’t much of a difference, tho. In fact, I believe the lack of difference could be the source of my dilemma. If you recall, my love for static typing was birthed after much frustration with the type systems I had known up to that point. I was throwing out the baby with the bath water. I suspect I dislike schemas because of SQL. It may be that I dislike SQL in particular, but like schemas in a general sense. For what it’s worth, I’m very interested in Datomic which has schemas. If I ever get around to really playing with it, perhaps I’ll be able to validate this suspicion.

In the meantime, I’m staying the course with the dynamically-typed MongoDB for my project. Given that my application is the only producer and consumer of my database, and I’m using static typing, I don’t see much value in having a static schema defined.

Tagged with: static-typing (16), databases (1)