3 ms·
That's a little weak as an argument isn't it. SQL and the relational model has nothing to do with stored procedures and you certainly don't have to, or need to
by wyuenho 15y ago
That's a little weak as an argument isn't it. SQL and the relational model has nothing to do with stored procedures and you certainly don't have to, or need to use stored procedures for reporting. In fact, prior to 2005, MySQL didn't support stored precedures for the longest time. How do you think those people did reporting? I don't know how you do reporting, but mind involves just a ridiculously simple and ugly web app that essentially just generates some HTML tables from a bunch of SQLAlchemy queries.
Why do I get the sense that the real reason most people use NoSQL stems from their destain of SQL, whatever that reason maybe...
- einhverfr 15y agoI am a total relational guy, BTW. But the fact is that there is a mismatch between how you have to think when doing SQL queries (thinking in sets) and OO programming (thinking in instructions). Anyone who has dealt with stored procedures written by app folks understands what a mess you get when you try to program one side in techniques aimed at the other. While NoSQL is a good choice for some environments, namely ones where ad hoc reporting is not likely to be needed and where other methods of interop are preferred (LDAP being a great example of something that could benefit from a NoSQL back-end), the fact is that this actually shows that, more often than not, you lose more than you gain by getting rid of the mismatch.... IOW, I think it is a moderately weak case for NoSQL in some environments and a strong case against in a much larger number of environments.....