5 ms·
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
by 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.