4 ms·
NoSQL isn't a replacement for SQL. It's a separate technology.
by jrgnsd 14y ago
NoSQL isn't a replacement for SQL. It's a separate technology.
- jurre 14y agoYes I understand that, but if SQL would become oracle expensive I think you will see a lot of companies/projects switching to one of the many nosql options that don't infringe IBM's patented API.
- roel_v 14y agoI don't think you understand. How can you switch from the one to the other if they're separate technologies? Going on foot is not a substitute for driving a car when we're talking about transporting 100 refrigerators from a port to a warehouse 300 km inland, it's only a substitute when we're talking about transporting a person less than a few kilometers and when time is of little importance. That's not to say that there are no alternatives to relational databases or SQL, but the leap to 'oh then NoSQL will take over' doesn't make much sense.
- Hoff 14y agoRaise the price of the current solution sufficiently, and the migration then makes a whole lot of sense. This even if the target product is less capable, less desirable or otherwise inferior, given a sufficiently large price delta (or hassle delta or product support delta, etc) then management and operations and finance will most definitely encourage the migration.
- jurre 14y agoBoth are in the business of storing data that can later be retrieved again, so I don't think your analogy really holds in this case. Maybe you are thinking of one particular nosql solution but I think almost all projects could find an alternative to a database that uses SQL. That is not to say that it shouldn't be a relational database or that there's a one shoe fits all solution out there.
- GlennS 14y agoI think you would really struggle to find adequate replacements for relational databases in at least two areas: reporting and ad-hoc queries.
- viraptor 14y agoMongodb has ad-hoc queries (not as simple as SQL, but still). Many engines can run huge aggregated queries (hadoop?) But I think the problem is placed in the wrong place. If SQL the language/API is copyrighted, then isn't it easier produce a new API with the same functionality?)