4 ms·

You're getting a little emotional, I guess. > If you're having 3 different codes reading the same DB you're doing something wrong Consider your average web ap

by pestaa 14y ago

You're getting a little emotional, I guess. > If you're having 3 different codes reading the same DB you're doing something wrong Consider your average web app where the database is manipulated by a public-facing app, an API and a background worker, possibly written in different languages by different companies. > non existing value in Mongo may be a NULL in SQL An empty value is a lot healthier in any code than an undefined variable/key to reference, isn't it? In NoSQL you have three states: non-existing, NULL or set. There are no guarantees which one a specific value will be in. SQL promises the value will not be missing, and it can ensure it is not left to NULL either. > you can't go to the grocery store by plane. Maybe maintaining databases in production is not about `visiting the grocery store by plane' in the first place. When the system has built-in guarantees, of course you'll move slower, and that is rarely a bad thing in production.

raverbashing 14y ago
"Consider your average web app where the database is manipulated by a public-facing app, an API and a background worker, possibly written in different languages by different companies." I don't remember being in a situation where that would be the case. Sure, it exists, but it would not be the ideal case. Usually I'd say you could have several different apps talking to your API (not directly to the DB) "An empty value is a lot healthier in any code than an undefined variable/key to reference, isn't it?" data.get('optional_field') in python, for example? Sure, there is some validation enforced by the DB in the relational case, but it is often not enough. Of course, in most SQL usages you are expected to shift most of the validation to the DB, in NOSQL this is much more restricted, but it's not better or worse, but different. Unless you are a bank or something like that, then for all means have all aspects in your Oracle DB
- pestaa 14y ago
  > Sure, it exists, but it would not be the ideal case. It is still not a sign that "you're doing it wrong". I prefer a single entry point to my data, too, but I still want my databases to be consistent in the sense that schema-like details are not coded in the client-side. > Sure, there is some validation enforced by the DB in the relational case, but it is often not enough. Agreed. Why worry about the mere existence of important keys? This was never a debate whether all storage logic belongs to the database or not. The article argues to make your schema visible and keep your data easy to query.

by pestaa 14y ago

raverbashing 14y ago

"Consider your average web app where the database is manipulated by a public-facing app, an API and a background worker, possibly written in different languages by different companies." I don't remember being in a situation where that would be the case. Sure, it exists, but it would not be the ideal case. Usually I'd say you could have several different apps talking to your API (not directly to the DB) "An empty value is a lot healthier in any code than an undefined variable/key to reference, isn't it?" data.get('optional_field') in python, for example? Sure, there is some validation enforced by the DB in the relational case, but it is often not enough. Of course, in most SQL usages you are expected to shift most of the validation to the DB, in NOSQL this is much more restricted, but it's not better or worse, but different. Unless you are a bank or something like that, then for all means have all aspects in your Oracle DB

pestaa 14y ago
> Sure, it exists, but it would not be the ideal case. It is still not a sign that "you're doing it wrong". I prefer a single entry point to my data, too, but I still want my databases to be consistent in the sense that schema-like details are not coded in the client-side. > Sure, there is some validation enforced by the DB in the relational case, but it is often not enough. Agreed. Why worry about the mere existence of important keys? This was never a debate whether all storage logic belongs to the database or not. The article argues to make your schema visible and keep your data easy to query.