Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Or because they wanted their data to be schemaless.

I once led a team creating a public-facing site based on its own custom forms/wizards. We had half a dozen internal departments wanting dozens of wildly varying forms defined, and decided we didn't want fixed schemas as future field requirements were unknown.

Rather than the corporate C#/SQL Server we went for Node/MongoDB, and we (successfully) ramped up a new system that transformed the power and cost-base of our public sector employer.

We were well chuffed, and it was deemed revolutionary (it also did cloud integration whilst pulling submissions, parsing/verifying, communicating, managing, and pushing into legacy IT systems, so not hyperbole).

And yet, despite the outcome, privately the team regretted the choice from about half-way through. I think for me the clue was when we introduced Mongoose to ... enforce a schema onto our schema-less Mongo collections and help out with the relational querying.

(Edit: I'm not saying schema-less is bad, I'm saying you need to be clear about when it's good.)



Yeah, that's what I was meaning to say. There's a difference between "the schema evolves" and "there is no schema (not even implicitly)". And it can also be "parts of the schema are fixed, others are not".

> I think for me the clue was when we introduced Mongoose to ... enforce a schema onto our schema-less Mongo collections and help out with the relational querying.

I agree that when you're doing things like that you're not really taking advantage of "schemaless", and that's probably a sign that that's not what you really want.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: