3 ms·

What is the probability that a boss will change his or her name That's obviously an example of something that will practically never happen, which is why it do

What is the probability that a boss will change his or her name That's obviously an example of something that will practically never happen, which is why it doesn't work all that well as a justification for ditching SQL databases altogether. I've never used NoSQL for anything, so there must be a lot that I'm missing, and that's why I asked. But it seems to me like you'd be digging up necessary information through quite a few steps if everything is "flat".

buff-a 15y ago
On the contrary, its the SQL database thats "digging up the necessary information through quite a few steps" it just that massive effort required by the SQL server is hidden from you, the programmer, by a one line bit of text called a SQL statement. So you do it all the time. Indeed we've been taught that denormalizing is the "proper" thing to do because otherwise "Bugs happen and referential constraints go a long way towards keeping your data clean." Digging kills you. I assert that SQL does the digging automatically, and thats exactly why it doesnt scale.
- white_devil 15y ago
  Yes, an SQL DB does the digging for you, but with NoSQL you'll be doing it yourself, right? Your app will most likely have some kind of "entities", and then records to represent them. How much information can and should you cram into records of various "types"? How much information do you typically end up duplicating across all those "entity records", and is it not a problem?
  - buff-a 15y ago
    As I said in my original complaint: I, and many others, spent a lot of time figuring out how to write apps that do it the "app engine way" That included learning NoSQL. At least that part was not a waste. There are no right answers to your questions, there are only right actions, starting with stepping outside the SQL box and writing an app using NoSQL. I started by thinking of a simple app that would be useful to me personally. I knew java servlets, I knew SQL, I knew all sorts of things, but after several iterations my app is architected like no app/server I've ever written before. Almost every iteration involved starting doing it the way I knew how, running into either roadblocks or major cognitive dissonance, and then rewriting it to fit these new-fangled constraints. Its been a huge learning experience. You might like to try it.
    - white_devil 15y ago
      I will end up using NoSQL sooner or later, of course. But now I'm just curious about whether there's a Right Way to do things. Could you just give me a brief description of how you arrange things (like "entities") with NoSQL?
richardw 15y ago
>> What is the probability that a boss will change his or her name > That's obviously an example of something that will practically never happen Women changing their name when they get married? A tiny assumption like that can make our software brittle. Now every model that caches the old name needs updating and you need to make sure there aren't any overlapping saves in any of those models that'll overwrite any items in your bulk update. If a single linked model has the wrong old-name cached, your data update process is buggy.
- white_devil 15y ago
  Now every model that caches the old name needs updating and you need to make sure there aren't any overlapping saves in any of those models that'll overwrite any items in your bulk update. If a single linked model has the wrong old-name cached, your data update process is buggy. Well, that sounds like the kind of stuff I'd like the other guy to talk about. How does he avoid the bad sides of having all your data in a key - value store? How would/do you?

buff-a 15y ago

On the contrary, its the SQL database thats "digging up the necessary information through quite a few steps" it just that massive effort required by the SQL server is hidden from you, the programmer, by a one line bit of text called a SQL statement. So you do it all the time. Indeed we've been taught that denormalizing is the "proper" thing to do because otherwise "Bugs happen and referential constraints go a long way towards keeping your data clean." Digging kills you. I assert that SQL does the digging automatically, and thats exactly why it doesnt scale.

white_devil 15y ago
Yes, an SQL DB does the digging for you, but with NoSQL you'll be doing it yourself, right? Your app will most likely have some kind of "entities", and then records to represent them. How much information can and should you cram into records of various "types"? How much information do you typically end up duplicating across all those "entity records", and is it not a problem?
- buff-a 15y ago
  As I said in my original complaint: I, and many others, spent a lot of time figuring out how to write apps that do it the "app engine way" That included learning NoSQL. At least that part was not a waste. There are no right answers to your questions, there are only right actions, starting with stepping outside the SQL box and writing an app using NoSQL. I started by thinking of a simple app that would be useful to me personally. I knew java servlets, I knew SQL, I knew all sorts of things, but after several iterations my app is architected like no app/server I've ever written before. Almost every iteration involved starting doing it the way I knew how, running into either roadblocks or major cognitive dissonance, and then rewriting it to fit these new-fangled constraints. Its been a huge learning experience. You might like to try it.
  - white_devil 15y ago
    I will end up using NoSQL sooner or later, of course. But now I'm just curious about whether there's a Right Way to do things. Could you just give me a brief description of how you arrange things (like "entities") with NoSQL?

richardw 15y ago

>> What is the probability that a boss will change his or her name > That's obviously an example of something that will practically never happen Women changing their name when they get married? A tiny assumption like that can make our software brittle. Now every model that caches the old name needs updating and you need to make sure there aren't any overlapping saves in any of those models that'll overwrite any items in your bulk update. If a single linked model has the wrong old-name cached, your data update process is buggy.

white_devil 15y ago
Now every model that caches the old name needs updating and you need to make sure there aren't any overlapping saves in any of those models that'll overwrite any items in your bulk update. If a single linked model has the wrong old-name cached, your data update process is buggy. Well, that sounds like the kind of stuff I'd like the other guy to talk about. How does he avoid the bad sides of having all your data in a key - value store? How would/do you?