Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Think before you Mongo

blog.runnable.com

Post reply on HN
Print view View original

81–90 of 101 posts

Re: Think before you Mongo

#81

Post by catnaroek »

ta0967 wrote: post #39
electricEmu wrote: post #32

Earlier quoted context omitted.

Speed of development and execution when I don't, and will likely never need, to query that way. I argue you ignored the silver bullet criticism and then immediately doubled down on SQL as the silver bullet.

you ignored the silver bullet criticism i don't think so, i simply refuse to have my arguments framed that way since i'm very well aware of the shortcomings present in what has so far passed for a "RDBMS". i consider velocitypsycho's argument ("Thinking RDBMS is a silver bullet is just as bad as thinking a document database is a silver bullet.") a non-sequitur: the former is a proper superset of the latter, that sent…

> the former is a proper superset of the latter

Exactly. Just like static typing is a proper superset of dynamic typing. More generally, structured X is a proper superset of unstructured X.

Re: Think before you Mongo

#82

Post by fl0wenol »

eldavido wrote: post #44
dccoolgai wrote: post #2

I agree... but at this point, it's tough to see with all the ink that's been spilled on these issues for years how you could think anything else. Maybe I read HN too much, but the manifold problems with MongoDB have been widely publicized for the past 6 years... it seems pretty close to conventional wisdom that you're going to have those problems if you decide to use Mongo.

You have to separate between "Mongo the database" and "Mongo as it's used by companies"; the latter causes far more problems than the former. I last used MongoDB seriously in 2012-2015. We had myriad operations problems including inconsistent indexing across shards (where some shards had an index created and others didn't, it was baffling), issues with the balancer not moving chunks properly, and more. Also it's just…

I should point out that for many organizations that have "big data" sitting somewhere, it usually is structured to begin with because it was collected by a repeatable process; or at the very least each piece of the whole (if it is a collection of stuff from different corners) has its' own internal consistency.

A challenge there is determining whether it makes sense to massage the data into a common schema for further analysis or to use an unstructured initial approach from the beginning. Sometimes you get to the former from the latter.

Re: Think before you Mongo

#83

Post by seagreen »

mixedCase wrote: post #68
seagreen wrote: post #47

Earlier quoted context omitted.

I don't think so -- I'm looking for a database that will actually enforce a JSON schema for you -- I don't think Postgres has any built-in support for JSON schematization. I could always do validation before inserting data, but that opens me up to error on my side which I'd like to avoid=)

You are trying to hammer a screw in. If what you want is a facility for the database to provide you with JSON on query, Postgres has a couple of functions for that, namely array_to_json and row_to_json: https://www.postgresql.org/docs/9.2/static/functions-json.ht...

I just want a key/value JSON database with schematization. If that's "trying to hammer a screw" then so be it.

Re: Think before you Mongo

#84

Post by seagreen »

PeCaN wrote: post #71
seagreen wrote: post #47

Earlier quoted context omitted.

I don't think so -- I'm looking for a database that will actually enforce a JSON schema for you -- I don't think Postgres has any built-in support for JSON schematization. I could always do validation before inserting data, but that opens me up to error on my side which I'd like to avoid=)

> I don't think Postgres has any built-in support for JSON schematization. Guess again. You can use JSON functions¹ in constraints: create table foo ( bar jsonb, constraint bar_count_is_positive check (bar->>'count' is not null and (bar->>'count')::integer >= 0) ); etc You could probably write a tool pretty easily to convert a JSON schema to Postgres constraints. 1. https://www.postgresql.org/docs/current/static/func…

Slick, thanks!

Re: Think before you Mongo

#85

Post by mixedCase »

seagreen wrote: post #83
mixedCase wrote: post #68

Earlier quoted context omitted.

You are trying to hammer a screw in. If what you want is a facility for the database to provide you with JSON on query, Postgres has a couple of functions for that, namely array_to_json and row_to_json: https://www.postgresql.org/docs/9.2/static/functions-json.ht...

I just want a key/value JSON database with schematization. If that's "trying to hammer a screw" then so be it.

May I ask why would you insist on such a thing? Is it about avoiding SQL?

Re: Think before you Mongo

#86

Post by seagreen »

findjashua wrote: post #59
seagreen wrote: post #34

Are there any key/value JSON databases that enforce JSON Schema (or some other schema language)? That seems way better to me in situations where you actually care about data integrity.

Any particular reason you want it at the db layer? Wouldn't having it at the query builder/orm layer suffice?

I think it would be useful in various situations.

In my particular case clients of different quality are connecting to a local datastore. I'd like to make sure that even if they mess up validation the data in the store still matches the schemas it claims to. Of course, I could have them connect to a local process instead and have that process handle validation before the data goes in the store, but it's always nice to avoid intermediaries.

Re: Think before you Mongo

#87

Post by seagreen »

mixedCase wrote: post #85
seagreen wrote: post #83

Earlier quoted context omitted.

I just want a key/value JSON database with schematization. If that's "trying to hammer a screw" then so be it.

May I ask why would you insist on such a thing? Is it about avoiding SQL?

I'd like access to JSON Schema's impressive tooling. I haven't seen anything like this for SQL schemas: http://jeremydorn.com/json-editor/

(Though if it exists please tell me, I'd be very interested!)

Re: Think before you Mongo

#88

Post by prodigal_erik »

findjashua wrote: post #59
seagreen wrote: post #34

Are there any key/value JSON databases that enforce JSON Schema (or some other schema language)? That seems way better to me in situations where you actually care about data integrity.

Any particular reason you want it at the db layer? Wouldn't having it at the query builder/orm layer suffice?

If your data store has existed for more than a year or two, it's very likely that other people in the org have written utilities against it (in different languages) that you personally are unaware of. You can reliably and atomically change the data store's business logic but not all the clients'.

Re: Think before you Mongo

#89

Post by redrummr »

gaius wrote: post #58
ta0967 wrote: post #39

Earlier quoted context omitted.

you ignored the silver bullet criticism i don't think so, i simply refuse to have my arguments framed that way since i'm very well aware of the shortcomings present in what has so far passed for a "RDBMS". i consider velocitypsycho's argument ("Thinking RDBMS is a silver bullet is just as bad as thinking a document database is a silver bullet.") a non-sequitur: the former is a proper superset of the latter, that sent…

It is a dead giveaway for inexperience, that some people refer to relational databases as "SQL databases".

But let's not forget that schema-less databases are often marketed as noSQL, so typing sql (quicker on phone) should be acceptable imo.

Re: Think before you Mongo

#90

Post by galdosdi »

electricEmu wrote: post #32
ta0967 wrote: post #15

Earlier quoted context omitted.

but we're not talking about silver bullets: we're talking about models which let you derive most information from your data. mathematics says you will get the most bang for your buck from the relational model. if you like hierarchical databases (data trees), consider that relational database gives you a forest: you can treat any datum as your tree root and bloom from there. with hierarchical, you're tied to a single…

Speed of development and execution when I don't, and will likely never need, to query that way. I argue you ignored the silver bullet criticism and then immediately doubled down on SQL as the silver bullet.

Weird, speed of development and execution is exactly why/when I would reach for Just using a SQL based RDBMS.

Whereas, going to a non-relational solution would be something I'd do when I needed to trade away simplicity and consistency in exchange for scaling/performance for specific cases where relational can't handle the write load. Losing the schema and ability to do joins and arbitrary queries and assume transactionality is a big loss that requires lots of work.

A dirty secret of NoSQL is that sure, part of their target audience is legitimate needs, but another part of their target audience is just new developers who don't have much experience with either SQL or NoSQL databases, and are easily mislead into buying the idea that NoSQL will be easier Because There's No Schema or Joins To Think About

Post reply on HN