Going tableless
Tableless html was all the rage a decade ago -- for a good reason.
One of the advantages was maintainability of the markup -- especially in a deeply nested table layout.
It also turned out, the table layout didn't actually fit the way we wanted to present the data. The rigid structure it enforced wasn't what we were after - and it also limited the freedom designers had to push forward and create next generation website and application layouts.
In the beginning though, it really was the only way to get stuff done -- and the best tool for the job. It was fun while it lasted -- but we are over it now.
Today -- we are entering a similar situation -- in databases, of all places.
Tableless databases are becoming all the rage today -- for a good reason.
One of the advantages of going tableless db is maintainability of the data -- especially with deeply nested data.
It turns out, the table schema doesn't fit the way we want to work with or present data. The rigid structure it enforces isn't what we are after either - and it also limits the freedom application designers have to push forward and create next generation websites and applications.
In the beginning though, it really was the only way to get stuff done -- and the best tool for the job. It was fun while it lasted -- but we are over it now.
One of the advantages was maintainability of the markup -- especially in a deeply nested table layout.
It also turned out, the table layout didn't actually fit the way we wanted to present the data. The rigid structure it enforced wasn't what we were after - and it also limited the freedom designers had to push forward and create next generation website and application layouts.
In the beginning though, it really was the only way to get stuff done -- and the best tool for the job. It was fun while it lasted -- but we are over it now.
Today -- we are entering a similar situation -- in databases, of all places.
Tableless databases are becoming all the rage today -- for a good reason.
One of the advantages of going tableless db is maintainability of the data -- especially with deeply nested data.
It turns out, the table schema doesn't fit the way we want to work with or present data. The rigid structure it enforces isn't what we are after either - and it also limits the freedom application designers have to push forward and create next generation websites and applications.
In the beginning though, it really was the only way to get stuff done -- and the best tool for the job. It was fun while it lasted -- but we are over it now.
Just don't forget that we turned deeply nested tables with complex hardcoded styles into deeply nested divs with complex hardcoded class names ;-P
ReplyDeleteImho, having no schema is actually bad for evolving applications.
ReplyDeleteThe schema is a blueprint of how data is structured. Any app developer that accesses the db can look at the schema as a contract to respect. And data tends to live longer than applications.
If your data is unstructured, and you evolve it over time, it means that all apps which access the data have to deal with all different versions of it - unless of course every time you change your schema you update all existing data to the new version.
But for schema-less data, mass updates often come down to a loop of read-and-update-every-item, which is not atomic and takes longer than a couple of UPDATE statements. Which means it is often skipped. (of course there could be more valid reasons to keep v1 data and v2 data at the same time).
So you end up having to write docs manually describing all versions of the data, and duplicating the logic to handle all cases in the different apps, which is also bound to cause more bugs.
But maybe you think that a db should never be accessed by more than one app at a time, and that the only API to access the data should be a RESTful service?
Anonymous: I didn't mean to say that a schema of some sort is bad -- in most real world applications these tend to be your objects which define the structure. A schema becomes apparent very quickly when browsing the database.
ReplyDeleteA rough schema is good, but attempting to throw everything into a rigid table structure doesn't work -- bye bye addressField2 addressField3 and phoneNumber2 columns! I cry everytime someone underestimate the time it takes to run ALTER TABLE to add that shippingAddress2 to the table.
As for "read-and-update-every-item" -- that's terrible. The tableless database you have tried seems absurdly incapable.
In general, migrating on-the-fly is very acceptable when rolling out new features -- you do the same thing when developing large scale apps with if (can_user_see_this_feature()) {} or similar to gradually roll out features anyway.
In vast majority of cases only one app accesses a database at a time, generally through some access point.
You may have some analytics tool running once a while on replicated instances of the database, but you wouldn't want that service to destroy your production traffic with bonkers queries purging your in-memory cache.
Similar with having multiple applications with completely different access pattern accessing the same database - oboy.