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

Goodbye MongoDB, Hello PostgreSQL

developer.olery.com

Post reply on HN
Print view View original

331–340 of 388 posts

Re: Goodbye MongoDB, Hello PostgreSQL

#331

Post by nemothekid »

michaelochurch wrote: post #167

My aversion to NoSQLs is derived from the readiness with which uninformed people dive into them, integrate them with their products, and create a web of complexity around something that should ideally be boring and reliable: the database. There are so many things that I've heard you "can't do in SQL" that are false, at least pertaining to Postgres. Semi-structured data, full-text search, "web scale" programming, geog…

I think 100TB deployments is a very high bar you've set for postgres. I think the one place NoSQL databases continue to serve (and where My/Postgresql don't) are highly available, sharded deployments - and people are running into the issue at the 10s of TBs (I can't imagine you'd want 5TB+ of data served from a single node - AWS largest SSD instance would be 6.4TB in RAID0, and serving your database off a single large RAID0 already sounds like a bad idea).

Not to say people aren't running these types of Postgres clusters, but its something not easily done.

I think the anti-SQL sentiment is a very MongoDB-esque thing, in that MongoDB tried to replace everything. Most of the other popular NoSQL solutions have very clear and cut use cases, and are pretty upfront about selecting the right database.

Re: Goodbye MongoDB, Hello PostgreSQL

#332

Post by prottmann »

jqm wrote: post #285

I haven't used MongoDB in production (the comments regarding reliability have been around for awhile), but playing around with it, I do like the json format and query structure. The issue I have with SQL (MS sql in the case of work) is the amount of cleverness involved in some queries I have seen. Among the old timers, it seems almost a badge of honer to develop the longest, most clever SQL query that does everything…

That is then not a problem of the SQL-Language, it is more a problem of the database design.

When you need really complex queries, you should think about a new db structure.

Re: Goodbye MongoDB, Hello PostgreSQL

#335

Post by rmc »

moe wrote: post #149
ad_hominem wrote: post #135

Earlier quoted context omitted.

Let's say you have a product search screen in your application. There's a text field for filtering on product title (WHERE title LIKE), one for filtering on UPC (WHERE upc LIKE), a couple range filters for min/max prices (WHERE price =), and then on the results screen the user sort on a few different columns (ORDER BY) as well as paginate and set number of results per-page (LIMIT + OFFSET). How exactly are you going…

How exactly are you going to "just write SQL" if the actual query statement needs to change based on the user input? How about something like this: s = Select.new s.add "WHERE title LIKE #{title}" if title s.add "WHERE price Note how I deliberately shuffled the order and didn't bother with escaping. Also note how anyone who knows SQL could immediately work with this, learning curve: 5 seconds. Why is there no ORM tha…

Now you have to be aware of SQL escaping to prevent SQL injection attacks.

Re: Goodbye MongoDB, Hello PostgreSQL

#336

Post by ttty »

chc wrote: post #68
ttty wrote: post #32

Earlier quoted context omitted.

I sincerely still prefer mongodb syntax because: - Fits well with a programming language; {a: data.x} is better than 'WHERE A="' + data.x + '"' (sanitize?) or similar which are harder to read. SQL queries are good for direct input, mongodb queries styles are better to be used with a programming language;

That is not how you do parameterized queries. With any civilized database library, it would be something along the lines of `"WHERE a = ? AND b = ?", data.x, data.y`, so that the parameters are like function parameters.

I've said similar because of this, so your comment is included in my statement. That doesn't change much

Re: Goodbye MongoDB, Hello PostgreSQL

#337

Post by ttty »

EpicEng wrote: post #189
ttty wrote: post #32

Earlier quoted context omitted.

I sincerely still prefer mongodb syntax because: - Fits well with a programming language; {a: data.x} is better than 'WHERE A="' + data.x + '"' (sanitize?) or similar which are harder to read. SQL queries are good for direct input, mongodb queries styles are better to be used with a programming language;

Your users don't give two craps about the syntax. The technology choice is one of application requirements. If you chose Mongo over e.g. a SQL DB because you like your code to look pretty then I have to admit that I wouldn't trust your software at all.

>Your users don't give two craps about the syntax.

Of course not, but your developers yes. Use a complex syntax and more bugs will appear. Do you care about bugs? No, but your users will.

> If you chose Mongo over e.g. a SQL DB because you like your code to look pretty then I have to admit that I wouldn't trust your software at all.

This is not my only reason.

Re: Goodbye MongoDB, Hello PostgreSQL

#338

Post by frik »

YorickPeterse wrote: post #85
jgrahamc wrote: post #13

As a greying developer I am most amused by people discovering that 'old' technologies like SQL databases work really well. The only useful piece of advice I can give a younger developer is... be careful when drinking the newtech koolaid. And one more thing: star = Sequel.lit('*') User.select(:locale) .select_append { count(star).as(:amount) } .select_append { ((count(star) / sum(count(star)).over) * 100.0).as(:percen…

It's not so much about not wanting to write/understand SQL (both are still very much required), but about composability. If you want to re-use bits of a SQL query written as a string literal your only option is string concatention or using some kind of string builder/template system. In both cases there's little validation of the query's correctness (syntax wise) until you actually run it. While I agree that many ORM…

Use an IDE like JetBrain's IDEA that checks the SQL syntax against the database.

Re: Goodbye MongoDB, Hello PostgreSQL

#339

Post by rikkus »

zaroth wrote: post #222
rikkus wrote: post #154

Earlier quoted context omitted.

Here's an example in C#. Imagine you're querying a database of products (here represented by integers). Users can enter filter parameters - you want to build your query dynamically based upon what they enter. With LINQ, you can do this kind of composing with no effort. You also get to run the same code on any kind of Queryable, so if you feel like doing some of the work in RAM and some using a DB, your query is usual…

FYI, you can also write it this way, although you may find it less readable, it emits the exactly same query to the DB, and I personally find it much more pleasing; IEnumerable Search(...) { return result .Where(i => !f.EvensOnly || i % 2 == 0) .Where(i => !f.Minimum.HasValue || i >= f.Minimum) .Where(i => !f.Maximum.HasValue || i Nit: EvensOnly should not be nullable since it has only two states.

I find this more readable. In fact, the code here looks more like this:

    .FilterByEvensOnly()
    .FilterByMinimum()
    .FilterByMaximum()
Obviously the example is trivialised and the real filters are more complex, requiring joins, but the pattern gives a very readable way of writing an efficient query.

Unfortunately EF produces an unreadable query when there are a few dozen filters, but the LINQ code is readable, so there hasn't been any difficulty debugging.

Re: Goodbye MongoDB, Hello PostgreSQL

#340

Post by onion2k »

rmc wrote: post #335
moe wrote: post #149

Earlier quoted context omitted.

How exactly are you going to "just write SQL" if the actual query statement needs to change based on the user input? How about something like this: s = Select.new s.add "WHERE title LIKE #{title}" if title s.add "WHERE price Note how I deliberately shuffled the order and didn't bother with escaping. Also note how anyone who knows SQL could immediately work with this, learning curve: 5 seconds. Why is there no ORM tha…

Now you have to be aware of SQL escaping to prevent SQL injection attacks.

Everyone who works with SQL should be aware of SQL escaping. There's nothing wrong using a library to do it for you, but what you should have an understanding of what the library is actually doing. Otherwise how could you possibly test it? Just by hoping it's right?
Post reply on HN