4 ms·

You absolutely can set the schema into stone, even when using a nosql database. That 'stone' is in your application code instead of the database though. And eve

You absolutely can set the schema into stone, even when using a nosql database. That 'stone' is in your application code instead of the database though. And even when you use SQL the schema can be changed anytime (by anyone, in practice in most small companies). ALTER TABLE ...

cyberferret 10y ago
I see your point, and we do tighten security on our database so that only certain users can perform ALTER, DROP etc. No doubt that can be done on NoSQL as well. I guess I was talking about 'inadvertent' database changes. It seems that things like a simple typo can end up creating new attributes in a table when you didn't want it to, e.g. lets say earlier in my code, I have: mytable.thisthing = 1 Then later on, someone mis-types: mytable.thatthing = 2 I now have TWO attributes in my table instead of having the original "thisthing" attribute changed to 2. An app with an SQL backend will usually throw an 'object/column not found' error if it recognises an attribute/column that is not on the original spec, but a couple of the NoSQL systems I've dealt with will happily take that line of code and work away with it, making debugging down the track a bit of a nightmare. I am sure you can harden your NoSQL service to prevent this sort of thing, but then it becomes a question of whether the extra effort involved is worth it as compared to sticking with SQL where you are more constrained, but have better control over inadvertent table changes.
- wereHamster 10y ago
  A simple typo in your SQL DDL statement can cause 'inadvertent' database changes. Just like you have your SQL schema defined in a central place, allow only a few select developers to make changes to it, and put any changes under extra scrutiny, you do the same when the schema is defined in your application code. '.. but what if typos' is not a valid argument. Not in 2016. You can use code reviews, tools (compilers, static type checkers) and good software engineering practices to avoid problems due to typos.
- deleted 10y ago
  [deleted]
- s_kilk 10y ago
  Another big issue is inadvertent type coercion. I once worked on a system which consisted of about a half-dozen services and MongoDB. At some point we noticed that a large percentage of the documents in a certain collection had somehow had a Date field coerced to String, which caused a bunch of stuff to not work correctly. That one took a while to track down.

cyberferret 10y ago

I see your point, and we do tighten security on our database so that only certain users can perform ALTER, DROP etc. No doubt that can be done on NoSQL as well. I guess I was talking about 'inadvertent' database changes. It seems that things like a simple typo can end up creating new attributes in a table when you didn't want it to, e.g. lets say earlier in my code, I have: mytable.thisthing = 1 Then later on, someone mis-types: mytable.thatthing = 2 I now have TWO attributes in my table instead of having the original "thisthing" attribute changed to 2. An app with an SQL backend will usually throw an 'object/column not found' error if it recognises an attribute/column that is not on the original spec, but a couple of the NoSQL systems I've dealt with will happily take that line of code and work away with it, making debugging down the track a bit of a nightmare. I am sure you can harden your NoSQL service to prevent this sort of thing, but then it becomes a question of whether the extra effort involved is worth it as compared to sticking with SQL where you are more constrained, but have better control over inadvertent table changes.

wereHamster 10y ago
A simple typo in your SQL DDL statement can cause 'inadvertent' database changes. Just like you have your SQL schema defined in a central place, allow only a few select developers to make changes to it, and put any changes under extra scrutiny, you do the same when the schema is defined in your application code. '.. but what if typos' is not a valid argument. Not in 2016. You can use code reviews, tools (compilers, static type checkers) and good software engineering practices to avoid problems due to typos.
deleted 10y ago
[deleted]
s_kilk 10y ago
Another big issue is inadvertent type coercion. I once worked on a system which consisted of about a half-dozen services and MongoDB. At some point we noticed that a large percentage of the documents in a certain collection had somehow had a Date field coerced to String, which caused a bunch of stuff to not work correctly. That one took a while to track down.