As a MarkLogic newbie, I became curious after happening upon an article on Jaxenter.com that attempts to diminish the value differentiators of a schema-agnostic database. In the post, the author asserts “there’s absolutely nothing that is really easier with ‘schemaless’ databases than with ‘schemaful’ ones.” Say what!? This must be crazy talk, I think to myself, as the author’s claims very specifically fly in the face of everything I’m learning about enterprise NoSQL. To get to the bottom of it, I reached out to a subject matter expert on the topic for clarification and edification.
What follows is an interview with my colleague, Ed Delacruz, who in addition to being a savvy enterprise NoSQL crusader is also a Principal Consultant at MarkLogic.
Fiona: The author of the article in question makes it sound as if it’s easier to change a schema in a RDBMS than in a schema-agnostic NoSQL database. I’m a bit taken aback by these assertions as this upends what I thought I knew about enterprise NoSQL. Can you shed some light on the author’s claims and the reasoning behind them?
Ed: It seems that the author is being a little hypocritical here, telling us how simple it is to change a schema in an RDBMS while he completely ignores the obvious difficulty of ensuring that the layers of the application on top of the database actually adhere to the changes made. In fact, the author’s project, jOOQ, apparently stems from this very challenge. On his website he’s even quoted as saying …
“You’re probably asking yourself why we need yet another database abstraction software in Java. Fair question. In our experience when writing applications against large and complex Oracle databases, Hibernate was not a good fit because we wanted to stay close to SQL: 2008 and to Oracle’s extensions. JDBC, on the other hand is verbose and causes a lot of quality and security headaches. So we rolled our own tailor-made little SQL builder. In fact, every company I have ever met rolled their own tailor-made SQL builder. But our business was not to write SQL builders, our business was to write brokerage logic.”
Fiona: So, the article’s assertion that making a change to an RDBMS schema is no more difficult than making a change to a schema-agnostic database is incompatible with the fact that the author is actually in the business of developing a SQL builder to remedy these recognized RDBMS shortcomings. Is that the gist?
Ed: Well, it’s clear that he believes that the layer dealing with relational databases is difficult at best and requires his additional software solution just to manage it successfully.
Fiona: What about making changes to a schema in a schema agnostic database? How would you compare the difficulty?
Ed: In an enterprise NoSQL database platform, additions or deletions to an XML or JSON document might only have to be changed in two places, the data (no schema to change) and the view layer.
On the other hand, in the traditional RDBMS n-tier stack, you’d have to change the:
And if that’s not messy enough, it gets worse for RDBMS if you add a complex structure like a shipping address that has a street number, city, state and zip code.
Fiona: Thanks for clearing that up, Ed. My last question is in regard to the author’s statement that dynamically typed schemas, like NoSQL, are lacking because “there’s no compiler (or IDE) that can help you infer the types with 100% certainty.” How do you respond to that?
Ed: IDEs (integrated development environments) do exist for interpreted languages, but neither IDEs nor compilers do anything when it comes to confirming that your code maps correctly with the database. It’s very debatable to imply that statically-typed schemas RDBMSs provide any quality improvements – especially when utilizing automated testing for QA (as is good practice). When pressed for the truth, anyone who has modified an RDBMS schema of an existing system doesn’t do it often because it is shifting the foundation of a whole stack of layers that sit on top of it. Further, I have seen firsthand how our agile enterprise NoSQL platform is able to adjust to changing business needs when rigid RBDMS-based platforms could not.
View all posts from Fiona Ehret-Kayser on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.Learn More
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
You can also ask us not to share your Personal Information to third parties here: Do Not Sell or Share My Info
We see that you have already chosen to receive marketing materials from us. If you wish to change this at any time you may do so by clicking here.
Thank you for your continued interest in Progress. Based on either your previous activity on our websites or our ongoing relationship, we will keep you updated on our products, solutions, services, company news and events. If you decide that you want to be removed from our mailing lists at any time, you can change your contact preferences by clicking here.