[Discuss] No-SQL Database Recommendation?

[markw at mohawksoft.com (markw at mohawksoft.com)]

> On 1/10/2015 9:49 PM, markw at 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 at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>