> On 1/10/2015 9:49 PM, ma...@mohawksoft.com wrote: >> This is so uninformed. There is *no* difference between a table with >> key/value in a sql database and a no-sql database. Almost every SQL >> database out there has, and has had for several years, JSON, XML, and >> other compound data types. > > Which are really just arbitrary data stored in table cells. That's not > the same thing as complex matrices. These kinds of data don't fit well > into relational databases. You can make them fit but then you're making > them fit which indicates that a relational database is the wrong tool.
Again, a "relational database" is a tool that is able to support a relational data model. That does not mean that it MUST be relational. C++ is able tp support an object oriented data model, but that does not mean you MUST use it as such. There are many reasons to use C++ as a "better C." Similarly, the idea that you can "join" data tables in SQL does not mean you must. Almost all databases today have aggregation/parsing functions for JSON, XML, CSV, etc. on table data. Calling SQL databases the "wrong tool" because it has a huge arsenal of tools to examine and access data makes no sense. > > >> Ahh "scale." What can you say about scale? Almost all people get it >> wrong >> if they have never done it, and if they have done it they know that any >> arbitrary technology is only a tool to build something that gets it >> right. > > Yep. And just so that this isn't a rag on relational databases, ALL > databases have a point beyond which performance plummets. Where these > points are for different technologies for given hardware and how the > system performs under these conditions are factors that should be > considered before choosing any technology. > > -- > Rich P. > _______________________________________________ > Discuss mailing list > Discuss@blu.org > http://lists.blu.org/mailman/listinfo/discuss > _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss