[Discuss] No-SQL Database Recommendation?

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

> On 01/10/2015 05:39 PM, markw at mohawksoft.com wrote:
>> There is this database religion thing that I don't get. Why at the
>> specification phase do you say you would like a no-sql solution, the,
>> ironically, enumerate a list of requirements that scream real database.
>
> I would like to find a no-SQL solution because I hate SQL, it is
> annoying. Worse, I have to program in one language for the bulk of my
> program, and then I have to embed code in a second language to talk to
> the database.

Well, just so you recognize it, that's pretty bad engineering. Avoiding a
particular technology because you "hate it" is a dubious starting
position.

>
> There might be technical reasons to cite for why some no-SQL program is
> better than some SQL program, but in my case it is pure prejudice. A bit
> like my preferring Python over Perl: there might be technical arguments
> for why Python is better than Perl, but one I like Python better. I am
> even getting kind of good at it.

The problem with this is that it isn't merely a language choice, it is a
technical strategy. A good engineer would be able to articulate pros and
cons of the various approaches.

There are voluminous discussions of this topic, internal prejudice is a
horrible reason to reject anything.

>
>> Using a free database like PostgreSQL will EASILY handle what you want
>> to do.
>
> Including finding the first few items in order really cheaply--without
> finding all possible items first? Okay, I'll look at PostgreSQL.

If you use something like PostgreSQL and limit your selection to [N] items
using, suprisingly, the "limit" keyword, it will come back after the Nth
item was found.

What's more exciting, assume you have a JSON, XML, or some other textual
aggregation technique, you can construct an index out of the result of a
parsing function!! i.e. if you have a data schema that has something like
this: <prodid>100</prodid>. You can use a function in your index and find
data faster than any "no-sql" could hope too.

>
> Maybe there is a less painful way to use it from Python than I found
> last I looked. I have always had a soft spot for PostgreSQL over MySQL,
> and now that Oracle has taken over MySQL, even more so.

As a side note, I understand your antipathy toward to SQL, but it is
merely just anther data access grammar with individual vendor variation,
no different than using different compression libraries.


>
> Thanks,
>
> -kb
>
>