Comment by endymi0n | Hacker News Reader

Comment by endymi0n | Hacker News Reader

Parent Full thread

Having delivered projects with about a dozen different relational and "schemaless" databases over the course of 15 years, I'm proud to say I'm siding 100% with this article by now:

https://orangematter.solarwinds.com/2015/02/24/schemaless-da...

> There’s no such thing as a schemaless database. I know, lots of people want a schemaless database, and lots of companies are promoting their products as schemaless DBMSs. And schemaless DBMSs exist. But schemaless databases are mythical beasts because there is always a schema somewhere. Usually in multiple places, which I will later claim is what causes grief.

When I started my career, I thought thinking about schema was an unneccessary complication that got in the way of me delivering valuable software. These days, I don't write a single line of code without having a good schema first, because it means I have understood the domain well enough to properly model it.

I heard it put more succinctly as "schema on read" and "schema on write". "Schemaless" is really "schema on read" - you're making some assumptions about the structure/values you're reading out, and you plan to take specific actions based on those. "Schema on write" is... create db/table/column defs up front, and force the data adhere to that schema, so that when you read it out, there's no question about whether it conforms to expectations or not.

Per the article you linked to, yes, there's always a schema. When/how you decide to verify the assumptions about the data is the question.

This is true, but I want to point out that conventional DBMS DDLs are horrible schema definition languages, yet are placed at the center of schema design by the DBMS.

They are horrible because because they hopelessly mix in all kinds of other concerns -- which is also why they are difficult to avoid.

IMO, where a schemaless database like this would be useful is not to avoid having a schema, but to allow a clean source-of-truth schema to be used, independent of all of the other concerns related to data access and storage.

(I'm commenting generally, BTW, not necessarily on this particular schemaless database.)

SFSQL does have a rules API not implemented in our Hosted Offering. We have plans to enable it.

You are correct there is a "schema" behind behind the scenes. Managing complex relationships between data and evolving those relationships can be a daunting task. SFSQL was created for that purpose.

It's also true that database schemas cause problems (I don't mean as in "versus schemalessness") because knowledge of schemas gets embedded into code.

but knowledge about db with schema is embedded in ... well schema. no?

Reply on news.ycombinator.com