Hacker News Reader

Comment by realusername | Hacker News Reader

I'm not in the banking industry but this sounds like the type of industry where you really need strong DB schemas in place and not something mongo-like ...

View on HN

I know things about the banking industry and let me tell you, just downgrade your expectations coming from the tech industry. Then downgrade them again, just to be sure.

And then upgrade your expectations of uptime and error tolerance by a few orders of magnitude.

That hasn't really been the case the past few years, in many places. (Especially the UK.)

Banks have notoriously terrible uptime! See, for example, the wide range of multi-hour to multi-week outages suffered by many UK banks in the last few years.

Most of the legacy retail banks regularly take down their online banking for hours at a time to do 'planned maintenance'. I've also heard that this happens to things like payment gateway APIs that aren't directly visible to consumers. Sometimes a Faster Payment might take a suspiciously long time and that's because the API fell over or was down for maintenance.

At least the data integrity is pretty good.

Didn’t realise the UK was so terrible. Banks here in Australia have many flaws but downtime is quite rare.

Mongodbs newer versions support schema validation by allowing you to register a JSON-Schema description against a collection and validate writes against It.

Fantastic. Knowing that my data was validated before being lost makes it so much better.

But the database doesn't need to be the component enforcing those schemas, right? They could validate the schema of a document on storage and retrieval. And keeping the schema version within a document would allow for multiple schema versions to exist within a single collection, which then would allow lazy migrations.

I'm not saying I'd choose Mongo specifically for this job (if for anything), but the lack of DB enforced schema might not be the biggest problem here.

This is the problem I’m alluding to in another comment about NoSQL in this thread. Why would you want to enforce the schema in code when the DB could do it for you? It becomes such a mess and such a burden for the developer!

That’s not always true. Often it’s not true. There’s a reason why we don’t have file systems that guarantee all .jpg files are valid JPEG files.

Now I want a filesystem that guarantees all .jpg files are valid JPEGs.

Until you need to do an emergency transfer of some recovered data volume and there’s a few dozen slightly corrupted JPEGs scattered throughout a few million files.

Also, I don’t think I’d want my filesystem deciding what qualifies as a valid JPEG.

But yes, I can see the theoretical appeal.

That means either only one place accesses the database (and becomes a bottleneck for change) or everywhere that accesses it has to keep their schemas in line.

Neither of those sound like great situations to be in.

I’m a big proponent of schema-rich SQL but I don’t see the argument here. Enforced schemas can be a bottleneck for change no matter where it’s enforced.

And just because some parts of a schema need to be “in line” doesn’t mean all of it must be. Maybe I care that “Customer ID” is enforced, but not “Australian Tax File Number” or “Document revision annotations”.

A lot of what banks do is filing forms. Thousands of ever-changing forms from millions of sources. Even things that aren’t forms are still very document-like: transcriptions, attachments, receipts, invoices, statements, letters... all of it more suited to document storage rather than tables.

No, you're clearly not in the banking industry because your assumption is completely backwards of reality.

Reply on news.ycombinator.com