Live data from Hacker News

Goodbye MongoDB, Hello PostgreSQL

developer.olery.com

281–290 of 388 posts

Re: Goodbye MongoDB, Hello PostgreSQL

#281

Earlier quoted context omitted.

This is a `negate` method in Arel (by Rails): class User Do this in SQL. Composability is the real boost, and you have composabiliy when you don't have to build a string in order to interact with the db.

unfortunately, where_values is also a private / unofficial API with no stability guarantees, so it can change at any time =/

True, but that's a problem related to Arel (which is poorly documented too... I think Rails is neglecting one of its greatest features).

Re: Goodbye MongoDB, Hello PostgreSQL

#282

You probably had a replica set and maybe an off-site replica. What are you using now, a single PostgreSQL instance, a master-slave cluster or any other distributed setup? If positive, which one of the many psql distributed technologies are you using? Thanks.

Before (Mongo): 1 primary, 2 secondaries, 2 arbiters Now (Postgres): 1 primary Most of our applications require write access in some shape or form, so at least the default replication of Amazon RDS doesn't cut it. Besides that we don't really need it so far, don't see the need for it in the coming months either.

Simple but sensible.

Re: Goodbye MongoDB, Hello PostgreSQL

#283

Earlier quoted context omitted.

Even with PL/pgSQL, there is no way to build a SQL statement dynamically _and_ safely -- it's all just string concatenation there, too. However, using `CASE`, `WITH` and `LATERAL` you can have a root `SELECT` that returns one of a few different queryable code paths, and `WITH`/`LATERAL` allow you to reuse definitions.

Use format() for safely constructing dynamic queries. http://www.postgresql.org/docs/9.4/static/functions-string.h...

You end up doing a lot of string concatenation even with that, though. It's not quite the same thing as having some kind of literal or combinator based setup.

  select(from('tab'), where(and(like('name','Mo%'),not(is('id',NULL)))

Re: Goodbye MongoDB, Hello PostgreSQL

#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 in one step. Inevitably, there are problems, and people have trouble figuring out why because they can't debug parts of the statement in isolation. In this case, it's as if they have written an entire program in one line and can't test parts in isolation. No doubt this is abuse of the language... and admittedly my SQL skills are not world class, but I keep scratching my head and wondering why they do this to themselves. If a query is so complex you can't tell what it is doing, and it misbehaves, perhaps you would have been better off with some smaller queries you join in the program... nothing against joins... one or two or three of them... but really....

I keep asking myself if I'm missing something, but I sort of doubt it.

Re: Goodbye MongoDB, Hello PostgreSQL

#286

Earlier quoted context omitted.

> This is the whole point of MongoDB: you assume the responsibility of managing the schema Who/what is the 'you' there? Don't 'you' have the responsibility of managing the schema either way? It's a question of whether you want to manage the schema through an rdbms, or... just in your application logic, I guess?

Manage as in write all the code that ensures adherence to the schema. If you say that the field called "score" is an int in a schema-ful DB, then insert an array, the DB will throw an error. If you do that in a schema-less DB, it will not unless you add a check yourself. If you are not using some type of unified DB access layer, you must perform this check every time you write a value. You must also perform the check…

(solely toward your final point) Many RDBMS' will optimize that for you. PostgreSQL has a bitmap structure on each row that indicates which columns are null and which have data in them. In addition, it automatically compresses certain data types. For example, strings that overflow to the point where they need to be stored in a secondary table (called "toast" in pg) will be automatically compressed.

Re: Goodbye MongoDB, Hello PostgreSQL

#287

Earlier quoted context omitted.

I agree with you. Also, we should be developing products that last. And be proud of that. Why does everything always have to be new?

You sound like someone who thinks we thinks we should still be using Cobol and IBM Series mainframes. Technology changes. It improves. It gets faster, easier and more responsive to business requirements. If you don't embrace change in the IT industry then get out. Because you simply won't survive.

Technology changes.

Yes.

It improves.

Sometimes.

It gets faster, easier and more responsive to business requirements.

Occasionally.

There are a lot of ideas in technology that are widely accepted, particularly by younger, less experienced generations, as being The Best Way to do things. However, if challenged, most of those people don't really know why they believe that. They have never personally seen any hard evidence that The Best Way is actually better than known alternatives. They have never spent significant time trying those alternatives for themselves to gain first-hand experience of the pros and cons. In fact, their belief is usually nothing more than a matter of faith, a blind trust in the dogma of the day and the rhetoric they find on-line or hear from their peers or managers.

See also: OOP, design patterns, UML and round-trip development processes, frameworks, ORMs, XML, dynamically typed languages, more frameworks, TDD, NoSQL databases, and so on, many of which were either invented or popularised as a way to work around the artificial problems created by one or more of the preceding items.

Of course I'm being a little facetious here. But if you think I'm entirely kidding, just spend a few minutes with Google and see how much advocacy there has been for each of those ideas in their day and how much actual data there has ever been to justify that advocacy. And really I'm being kind here, because you talked about things that are supposedly "faster, easier and more responsive to business requirements" and I didn't even mention words like "agile" or "craftsmanship" in my list.

If you don't embrace change in the IT industry then get out. Because you simply won't survive.

I embrace using the right tool for the job. Whether it's new and shiny or old but tried-and-tested doesn't really matter, though if I had to pick one or the other for some bizarre reason, I'd pick tried-and-tested eight days a week. There have been only a few truly significant advances in the past decade or two, but very many technologies that were initially much-hyped but then failed to stand the test of time for exactly the reasons that critics outside the hype bubble had always predicted.

Re: Goodbye MongoDB, Hello PostgreSQL

#288

The author's assertion that "Another problem with MySQL is that any table modification (e.g. adding a column) will result in the table being locked for both reading and writing. This means that any operation using such a table will have to wait until the modification has completed." is no longer correct as of Mysql 5.6: http://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-o... If you specify ALGORITHM=INPLACE,L…

Small clarification:

> If you specify ALGORITHM=INPLACE,LOCK=NONE you can alter table without blocking reads and writes. We have used this method successfully in Amazon RDS when updating schemas.

The use-case of ALGORITHM=INPLACE and LOCK=NONE is to produce an error if the modification you are attempting is not supported in this mode. i.e. even if you don't specify LOCK=NONE, that doesn't mean it will lock.

This is useful in preventing guessing games (i.e. you think its LOCK=NONE, but for some reason it's not compatible...)

Re: Goodbye MongoDB, Hello PostgreSQL

#289

Earlier quoted context omitted.

Your comment made me realize why I prefer to work in ORMs instead of raw SQL, even though I'm frequently frustrated by their limitations - it all comes down to composability. The mongodb syntax looks like it supports composing statements much more readily than SQL. It makes me wonder if there's been any serious work done making a query language that's fully as general as SQL, but is designed to be safely and easily c…

> The mongodb syntax looks like it supports composing statements much more readily than SQL. It makes me wonder if there's been any serious work done making a query language that's fully as general as SQL, but is designed to be safely and easily composable so that you can build queries up from parts. Haven't you noticed that it's exactly what the Sequel snippet does? It's also what SQLAlchemy's Expression Language do…

The ORMs I've used have always tried to map tables to classes (or whatever similar language structure is available). That works well almost all the time, but I get tripped up when the queries get to be more complex or specialized to a particular use.

I haven't used SQLAlchemy's expression language, but glancing over it now it looks like it might be just what I was looking for (at least for python), so thanks for the pointer.

Re: Goodbye MongoDB, Hello PostgreSQL

#290

Earlier quoted context omitted.

Use format() for safely constructing dynamic queries. http://www.postgresql.org/docs/9.4/static/functions-string.h...

You end up doing a lot of string concatenation even with that, though. It's not quite the same thing as having some kind of literal or combinator based setup. select(from('tab'), where(and(like('name','Mo%'),not(is('id',NULL)))

You can get a similar syntax with format() by nesting format() calls such as:

  EXECUTE format('SELECT * FROM tab %s', format('WHERE %I IS NOT NULL', 'id'));
Post reply on HN