4 ms·

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 ...

jusssi 6y ago
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.
- arcturus17 6y ago
  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!
  - sjwright 6y ago
    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.
    - WJW 6y ago
      Now I want a filesystem that guarantees all .jpg files are valid JPEGs.
      - sjwright 6y ago
        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.
- AndrewDucker 6y ago
  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.
  - sjwright 6y ago
    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”.
zwaps 6y ago
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.
- sjwright 6y ago
  And then upgrade your expectations of uptime and error tolerance by a few orders of magnitude.
  - tpmx 6y ago
    That hasn't really been the case the past few years, in many places. (Especially the UK.)
  - rossng 6y ago
    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.
    - sjwright 6y ago
      Didn’t realise the UK was so terrible. Banks here in Australia have many flaws but downtime is quite rare.
sjwright 6y ago
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.
Kiro 6y ago
No, you're clearly not in the banking industry because your assumption is completely backwards of reality.
thawkins 6y ago
Mongodbs newer versions support schema validation by allowing you to register a JSON-Schema description against a collection and validate writes against It.
- GuuD 6y ago
  Fantastic. Knowing that my data was validated before being lost makes it so much better.

jusssi 6y ago

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.

arcturus17 6y ago
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!
- sjwright 6y ago
  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.
  - WJW 6y ago
    Now I want a filesystem that guarantees all .jpg files are valid JPEGs.
    - sjwright 6y ago
      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.
AndrewDucker 6y ago
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.
- sjwright 6y ago
  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”.

zwaps 6y ago

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.

sjwright 6y ago
And then upgrade your expectations of uptime and error tolerance by a few orders of magnitude.
- tpmx 6y ago
  That hasn't really been the case the past few years, in many places. (Especially the UK.)
- rossng 6y ago
  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.
  - sjwright 6y ago
    Didn’t realise the UK was so terrible. Banks here in Australia have many flaws but downtime is quite rare.

sjwright 6y ago

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.

Kiro 6y ago

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

thawkins 6y ago

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

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