6 ms·

RDBMS only provides a limited degree of 'validation'. It still must exist fairly comprehensively in the app.

jacques_chester 8y ago
Databases are, as their name suggests, closest to the data. Applications generally can't recreate ACID properties and specifically, they shouldn't be trying to.
- sonnyblarney 8y ago
  "Applications generally can't recreate ACID properties" - why would they? ACID and 'data validation' are generally separate issues. Data generally has to be validated as it enters the business logic, before it gets stored in a DB. While a DB may in some cases ensure that data adheres to a schema, this usually does not fulfill all of the validation requirements.
  - jacques_chester 8y ago
    Validation often requires examine a model beyond "is this an int?". That model needs to be self-consistent. That requires atomic movements from consistent state to consistent state. You can do that yourself. Or let the database do it. For things where you can't express it in a database schema, sure. But you'd be surprised how far it gets you.
int_19h 8y ago
On the contrary, RDBMS provides far more opportunity for validation, because it has all the data at its disposal, which can be queried as needed without the expense of crossing the boundary.
- Bucephalus355 8y ago
  What is the purpose of validation would you say with modern computers? At one time, specifying the exact number of chars was good for squeezing out as much storage as possible, but less so today.
  - sonnyblarney 8y ago
    Validation is almost always a function of business logic, not 'storage compression'.
  - baroffoos 8y ago
    Its still absolutely critical for almost everything. Some use cases: * My code depends on this value always existing so make this not null * My code is doing math on this value so make sure it is always a number * This record belongs to other record, make sure other record can not be deleted while this one still exists Modern computers change next to nothing with the need to validate data. The worlds fastest computer wont tell you how to add a number that doesn't exist.
- sonnyblarney 8y ago
  First, most 'noSQL' DB's (including Mongo) have data validations anyhow, rendering the discussion almost moot. " RDBMS provides far more opportunity for validation" This can't be true. The application layer, which ultimately contains all 'knowledge' of all aspects of the business, including data from all other resources, can obviously 'provide more opportunity' for validation than any DB possibly can. Moreover, 'validation' generally implies aspects which are inherently application specific ergo, doing this purely in the data layer almost implies an intersection of concerns. Validation in almost every case must be done on the app layer, so anything we get from the DB is an added benefit. Also, data generally has to be validated when it enters into the business logic, long before it gets into the DB, moreover, there are usually data elements that are not persisted, and must be validated anyhow, again illustrating the requirement for validation above the DB.
  - int_19h 8y ago
    First of all, we were talking about validation of data in the database, specifically. > 'validation' generally implies aspects which are inherently application specific Not at all. Taking this at face value implies that some app can write data to the database that is valid according to that app, and then another app can read data that is invalid from its perspective, and have to deal with it. That doesn't make sense - data is data, it's either valid, or it's not. That's why the schema is about the data, not about the app. > Validation in almost every case must be done on the app layer For UX reasons, mostly, yes. But it's usually much more basic than what e.g. triggers would do in the DB itself. I'm not saying that there's nothing to validate outside of the DB, either. But for the data that is in the DB, the DB itself can usually do a better job.
    - thomaslangston 8y ago
      The general idea I've seen (for both SQL and NoSQL databases) is two apps never should write to the same database to ensure separation of concerns. Some API layer instead handles all write operations. Disclaimer: MongoDB employee. All opinions are my own.
      - 8y ago

Databases are, as their name suggests, closest to the data. Applications generally can't recreate ACID properties and specifically, they shouldn't be trying to.

sonnyblarney 8y ago
"Applications generally can't recreate ACID properties" - why would they? ACID and 'data validation' are generally separate issues. Data generally has to be validated as it enters the business logic, before it gets stored in a DB. While a DB may in some cases ensure that data adheres to a schema, this usually does not fulfill all of the validation requirements.
- jacques_chester 8y ago
  Validation often requires examine a model beyond "is this an int?". That model needs to be self-consistent. That requires atomic movements from consistent state to consistent state. You can do that yourself. Or let the database do it. For things where you can't express it in a database schema, sure. But you'd be surprised how far it gets you.

int_19h 8y ago

On the contrary, RDBMS provides far more opportunity for validation, because it has all the data at its disposal, which can be queried as needed without the expense of crossing the boundary.

Bucephalus355 8y ago
What is the purpose of validation would you say with modern computers? At one time, specifying the exact number of chars was good for squeezing out as much storage as possible, but less so today.
- sonnyblarney 8y ago
  Validation is almost always a function of business logic, not 'storage compression'.
- baroffoos 8y ago
  Its still absolutely critical for almost everything. Some use cases: * My code depends on this value always existing so make this not null * My code is doing math on this value so make sure it is always a number * This record belongs to other record, make sure other record can not be deleted while this one still exists Modern computers change next to nothing with the need to validate data. The worlds fastest computer wont tell you how to add a number that doesn't exist.
sonnyblarney 8y ago
First, most 'noSQL' DB's (including Mongo) have data validations anyhow, rendering the discussion almost moot. " RDBMS provides far more opportunity for validation" This can't be true. The application layer, which ultimately contains all 'knowledge' of all aspects of the business, including data from all other resources, can obviously 'provide more opportunity' for validation than any DB possibly can. Moreover, 'validation' generally implies aspects which are inherently application specific ergo, doing this purely in the data layer almost implies an intersection of concerns. Validation in almost every case must be done on the app layer, so anything we get from the DB is an added benefit. Also, data generally has to be validated when it enters into the business logic, long before it gets into the DB, moreover, there are usually data elements that are not persisted, and must be validated anyhow, again illustrating the requirement for validation above the DB.
- int_19h 8y ago
  First of all, we were talking about validation of data in the database, specifically. > 'validation' generally implies aspects which are inherently application specific Not at all. Taking this at face value implies that some app can write data to the database that is valid according to that app, and then another app can read data that is invalid from its perspective, and have to deal with it. That doesn't make sense - data is data, it's either valid, or it's not. That's why the schema is about the data, not about the app. > Validation in almost every case must be done on the app layer For UX reasons, mostly, yes. But it's usually much more basic than what e.g. triggers would do in the DB itself. I'm not saying that there's nothing to validate outside of the DB, either. But for the data that is in the DB, the DB itself can usually do a better job.
  - thomaslangston 8y ago
    The general idea I've seen (for both SQL and NoSQL databases) is two apps never should write to the same database to ensure separation of concerns. Some API layer instead handles all write operations. Disclaimer: MongoDB employee. All opinions are my own.
    - 8y ago