4 ms·

>where you can enforce the rules of your data in a single place That's called a database. That entire post could be summarized as "look, some dumbass didn't p

>where you can enforce the rules of your data in a single place That's called a database. That entire post could be summarized as "look, some dumbass didn't put a foreign key constraint on the currency column".

smallegan 15y ago
Your suggesting that all data is stored in the same database. In most large environments this is not the case, in many cases data is coming to and from many 3rd party systems and it is the job of the developer to make these systems work together.
- SomeOtherGuy 15y ago
  No, I am suggesting that we already have a solution for "I need a single authoritative source of rules about this data". And it is called a database. Treating your database like it is just dumb storage is what creates these problems in the first place.
  - Domenic_S 15y ago
    > It is called a database. Nice. I'm going to spoil the surprise and just tell you: in enterprise environments there are tens or hundreds of databases talking to one another through all kinds of different layers of orchestration, and the One Person In Charge of database #24 is never the One Person In Charge of databas #81. What you're talking about is a "Single Source of Truth", and for most large companies it's a pipe dream. Very large technology companies try to -- and somewhat do -- solve some permutations of this problem (see: IBM Initiate), but enterprise environments are by and large held together with bubble gum and duct tape. Don't even get me started on data sets that have to join living in different timezones when timestamp is critical. There are rules for this sort of thing, but chances are nobody who's on the project knows what they are.
    - SomeOtherGuy 15y ago
      >What you're talking about is a "Single Source of Truth" What is with all the random nonsense comments here lately? I am not suggesting a single source of truth, the person I replied to was. I simply pointed out that if you are trying to have such a source, the database is where to put it, not a shared library that all the codebases maybe use sometimes.
x3c 15y ago
Even when using ACID compliant databases, Consistency check should be replicated in your application layer, atleast for mission critical data. But maybe that's just me.
- SomeOtherGuy 15y ago
  >Even when using ACID compliant databases I am genuinely sad that such a statement would ever be uttered. "Even when"? Why would you choose to use a database that isn't reliable? >Consistency check should be replicated in your application layer, atleast for mission critical data. Maybe if there were some way to do that, but there isn't. It doesn't get replicated, it gets re-implemented, which is quite different. And it results in application code in app X that says data is bad while the DB says it is ok, and then application Y also says it is ok and inserts it fine, and then app X pukes getting it back out later, etc. Leave the DB in charge of the rules and when it gives you an error, you can go ahead and relay that error to the user (in a nicer format one would assume).
  - x3c 15y ago
    >I am genuinely sad that such a statement would ever be uttered. "Even when"? Why would you choose to use a database that isn't reliable? How many NoSQL DBs are guaranteed ACID compliant? They are reliable but not ACID. And consistency checks are put in application layer >Maybe if there were some way to do that, but there isn't. It doesn't get replicated, it gets re-implemented,.... I want to ensure that X is always equal to the sum of Y and Z. I can achieve consistency at Database. But It would be a waste of resources to query DB for consistency on each request when such check can be implemented at application level only, or even better at client side (assuming web application).

smallegan 15y ago

Your suggesting that all data is stored in the same database. In most large environments this is not the case, in many cases data is coming to and from many 3rd party systems and it is the job of the developer to make these systems work together.

SomeOtherGuy 15y ago
No, I am suggesting that we already have a solution for "I need a single authoritative source of rules about this data". And it is called a database. Treating your database like it is just dumb storage is what creates these problems in the first place.
- Domenic_S 15y ago
  > It is called a database. Nice. I'm going to spoil the surprise and just tell you: in enterprise environments there are tens or hundreds of databases talking to one another through all kinds of different layers of orchestration, and the One Person In Charge of database #24 is never the One Person In Charge of databas #81. What you're talking about is a "Single Source of Truth", and for most large companies it's a pipe dream. Very large technology companies try to -- and somewhat do -- solve some permutations of this problem (see: IBM Initiate), but enterprise environments are by and large held together with bubble gum and duct tape. Don't even get me started on data sets that have to join living in different timezones when timestamp is critical. There are rules for this sort of thing, but chances are nobody who's on the project knows what they are.
  - SomeOtherGuy 15y ago
    >What you're talking about is a "Single Source of Truth" What is with all the random nonsense comments here lately? I am not suggesting a single source of truth, the person I replied to was. I simply pointed out that if you are trying to have such a source, the database is where to put it, not a shared library that all the codebases maybe use sometimes.

x3c 15y ago

Even when using ACID compliant databases, Consistency check should be replicated in your application layer, atleast for mission critical data. But maybe that's just me.

SomeOtherGuy 15y ago
>Even when using ACID compliant databases I am genuinely sad that such a statement would ever be uttered. "Even when"? Why would you choose to use a database that isn't reliable? >Consistency check should be replicated in your application layer, atleast for mission critical data. Maybe if there were some way to do that, but there isn't. It doesn't get replicated, it gets re-implemented, which is quite different. And it results in application code in app X that says data is bad while the DB says it is ok, and then application Y also says it is ok and inserts it fine, and then app X pukes getting it back out later, etc. Leave the DB in charge of the rules and when it gives you an error, you can go ahead and relay that error to the user (in a nicer format one would assume).
- x3c 15y ago
  >I am genuinely sad that such a statement would ever be uttered. "Even when"? Why would you choose to use a database that isn't reliable? How many NoSQL DBs are guaranteed ACID compliant? They are reliable but not ACID. And consistency checks are put in application layer >Maybe if there were some way to do that, but there isn't. It doesn't get replicated, it gets re-implemented,.... I want to ensure that X is always equal to the sum of Y and Z. I can achieve consistency at Database. But It would be a waste of resources to query DB for consistency on each request when such check can be implemented at application level only, or even better at client side (assuming web application).