{"id":1789,"date":"2014-12-02T00:00:00","date_gmt":"2014-12-01T23:00:00","guid":{"rendered":"https:\/\/wwwneu.strehle.de\/tim\/weblog\/archives\/2014\/12\/02\/1751\/"},"modified":"2025-11-07T14:11:17","modified_gmt":"2025-11-07T13:11:17","slug":"1751","status":"publish","type":"post","link":"https:\/\/www.strehle.de\/tim\/weblog\/archives\/2014\/12\/02\/1751\/","title":{"rendered":"Schema flexibility for power users"},"content":{"rendered":"\n<p>In software, the thing I\u2019m most excited about at the moment is <strong>schema flexibility<\/strong>. (I first saw that term in a <a href=\"https:\/\/twitter.com\/ekolvitz\/status\/533039154024562688\">tweet by Emily Ann Kolvitz<\/a>.) I think we\u2019re losing a lot of valuable metadata, and business value, because the software we keep our structured data in makes it so <strong>hard to change the data model<\/strong>.<\/p>\n\n\n\n<p>Example #1: Your system stores each customer\u2019s e-mail address. Now you want to extend this to allow multiple addresses per customer, each with a label (\u201cwork e-mail\u201d, \u201cpersonal e-mail\u201d etc.)<\/p>\n\n\n\n<p>Example #2: Your archival system knows the publication date for each of your newspaper articles. Now you want to archive Web articles as well, but their publication date includes the time of day whereas print articles only have the day.<\/p>\n\n\n\n<p>Example #3: Users can already add simple custom fields (say, \u201cPhotographer name\u201d), but sometimes they really need to add custom structures and relations (i.e. a separate \u201cPhotographer\u201d record with its own fields, and links to to these records).<\/p>\n\n\n\n<p>Sounds simple? Well, you\u2019ll need a developer and database administrator for all of the above. And it might be a lot of work for them.<\/p>\n\n\n\n<p>Most structured data still lives in <strong>relational (SQL) databases<\/strong>. They\u2019re wonderful, but they make it especially hard to change your data model. Demian Hess illustrates this in the first part of his excellent <a href=\"https:\/\/www.linkedin.com\/pulse\/20141118002200-13840447-dam-and-the-need-for-flexible-metadata-models\/\">DAM and the Need for Flexible Metadata Models<\/a> series: \u201cAs new asset types are discovered, you need to restructure the database by adding new tables or new columns. Database restructuring requires expensive and disruptive changes in queries and application-layer logic. [\u2026] The fundamental flaw is that we are attempting to define all the attributes for every type of digital asset in our data model in advance. In other words, we are imposing an inflexible data model.\u201d<\/p>\n\n\n\n<p>This rigidity is one reason for the current wave of <a href=\"http:\/\/www.mongodb.com\/nosql-explained\">NoSQL databases<\/a>. There\u2019s document databases like MongoDB, way more flexible but they \u201ctend to suffer in supporting relationships between documents\u201d (Demian Hess \u2013 <a href=\"https:\/\/www.linkedin.com\/pulse\/20141201213211-13840447-dam-and-flexible-metadata-using-a-document-database\/\">DAM and Flexible Data Models Using Document Databases<\/a>). Graph databases or RDF triple stores like <a href=\"https:\/\/brightstardb.readthedocs.io\/en\/stable\/Why_BrightstarDB_\/\">BrightstarDB<\/a> also fall into the <strong>NoSQL<\/strong> category. <a href=\"\/tim\/weblog\/archives\/2013\/02\/08\/1555\">I don\u2019t like their data model<\/a>, but they do give you schema flexibility.<\/p>\n\n\n\n<p>To be exact, these NoSQL products give <em>your developers<\/em> schema flexibility\u2026 In my opinion, the real game-changer is when <strong>power users can extend the data model<\/strong>. Of course this isn\u2019t for everyone. But why can\u2019t the librarian, a skilled user in marketing or sales, or your IT support staff enhance the database schema? And not just with a simplistic custom field, but any structure that makes sense? Having to wait for your developer (or worse, for a vendor) costs time and money, and kills many sensible ideas. Yes, developers may be needed to add polish or use the new data in integrations with other software. But power users should be able to model the data exactly as your business needs it.<\/p>\n\n\n\n<p>This vision is why I\u2019ve started to experiment with a user-friendly Topic Maps engine, <a href=\"https:\/\/github.com\/tistre\/TopicCards\">TopicCards<\/a>. It\u2019s in a very early stage right now, but I\u2019ll have something for you to play with sometime in 2015 \ud83d\ude42<\/p>\n\n\n\n<p>P.S.: See what I mean in the <a href=\"https:\/\/blog.sourcefabric.org\/en\/news\/blog\/2879\/So-just-what-is-Superdesk-anyway.htm\">Sourcefabric Superdesk description<\/a>: \u201cco-ordinated, managed and configured by journalists to suit their normal workflow \u2014 and for them to change that on the fly to cope with events needing a non-standard workflow.\u201d<\/p>\n\n\n\n<p>P.P.S.: Loosening your database schema has its disadvantages, of course. See Martin Fowler\u2019s slide deck on <a href=\"http:\/\/martinfowler.com\/articles\/schemaless\/\">Schemaless Data Structures<\/a>. But I\u2019m siding with one of his conclusions: \u201cCustom fields and non-uniform types are both good reasons to use a schemaless approach.\u201d<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In software, the thing I\u2019m most excited about at the moment is schema flexibility. (I first saw that term in a tweet by Emily Ann Kolvitz.) I think we\u2019re losing a lot of valuable metadata, and business value, because the software we keep our structured data in makes it so hard to change the data [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_share_on_mastodon":"0"},"categories":[1],"tags":[],"class_list":["post-1789","post","type-post","status-publish","format-standard","hentry","category-weblog"],"share_on_mastodon":{"url":"","error":""},"_links":{"self":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1789","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/comments?post=1789"}],"version-history":[{"count":2,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1789\/revisions"}],"predecessor-version":[{"id":2260,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1789\/revisions\/2260"}],"wp:attachment":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/media?parent=1789"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/categories?post=1789"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/tags?post=1789"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}