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

“Fashion Is Hard. PostgreSQL Is Easy” [video]

tech.zalando.com

Post reply on HN
Print view View original

91–100 of 140 posts

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#91

Post by ma2rten »

sandGorgon wrote: post #83
emilburzo wrote: post #48

I love PostgreSQL. But for a personal project I went with MongoDB, because my data set was a perfect match for mongo's design. Now I love mongo too, I'm amazed with how easy it has been to maintain 100% uptime on comodity hardware (one server is literally in a room in my apartment) through all the random server downtimes, upgrades, migrations, etc. And now I have more ideas for some personal projects, and they would…

do take a look if you can leverage jsonb datastructure of postgres - you get 80% of the power of mongo and all the advantages of postgres. https://www.compose.io/articles/is-postgresql-your-next-json...

Actually the article you posted makes the case that postgres is not a good json database, because it can not modify json documents in place.

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#92

Post by noir_lord »

bshimmin wrote: post #62
noir_lord wrote: post #54

Earlier quoted context omitted.

I just remembered it as \d as display and \dt as display tables. I often invent mnemonics that only mean something to me until muscle memory kicks in.

Here's a nice one-page cheat sheet, of which about 75% you will probably never need to use: http://www.postgresonline.com/downloads/special_feature/post...

Thats excellent, thanks :).

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#93

Post by mgkimsal »

mhd wrote: post #39

I had a job interview at Zalando a while ago, and apart from the huge bunch of bananas at the entrance to the developer's den, the one thing I remember most about was the fact that apparently they're using stored procedures for basically any database transaction. Which is probably a more unorthodox use of databases these days, at least for Postgres (I've heard it was more common for SQL Server and I once had the ques…

I've seen this pattern used a few places (sprocs for every single interaction). Seems like a lot of development overhead, but at at least one place I saw them in use at, the db admin and one of his appointees were the only people allowed to even write these things. Devs were just given connection privileges to run those sprocs, nothing else. Things worked, but the process didn't seem terribly ... productive. Apparently it was partially in reaction to some previous developer who'd done all the SQL by hand, and no one else could understand it. They didn't seem to realize they'd just shifted the problem from a developer to a dba.

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#94

Post by neilc »

ma2rten wrote: post #91
sandGorgon wrote: post #83

Earlier quoted context omitted.

do take a look if you can leverage jsonb datastructure of postgres - you get 80% of the power of mongo and all the advantages of postgres. https://www.compose.io/articles/is-postgresql-your-next-json...

Actually the article you posted makes the case that postgres is not a good json database, because it can not modify json documents in place.

PG 9.5 will improve this situation somewhat, e.g., builtin functions like jsonb_set(), and overloading the '-' operator for jsonb values:

http://www.postgresql.org/docs/devel/static/functions-json.h...

That said, if you're doing a lot of mutation of large JSON documents stored in a single Postgres row value, the storage/concurrency control behavior still won't be ideal.

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#96

Post by UserRights »

I found this video to be much more interesting https://youtu.be/zsF1vfHBMBI

BTW I would like to send out a BIG THANK YOU to the guys that did the videos - this is such an important and great service for everybody who could not attend the conference, so: THANK YOU VERY MUCH!

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#97

Post by valgog »

ma2rten wrote: post #91
sandGorgon wrote: post #83

Earlier quoted context omitted.

do take a look if you can leverage jsonb datastructure of postgres - you get 80% of the power of mongo and all the advantages of postgres. https://www.compose.io/articles/is-postgresql-your-next-json...

Actually the article you posted makes the case that postgres is not a good json database, because it can not modify json documents in place.

Actually without providing some benchmark results, the statement, that PostgreSQL has performance problems because of on-copy updating of JSONB, is groundless.

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#98

Post by valgog »

neilc wrote: post #94
ma2rten wrote: post #91

Earlier quoted context omitted.

Actually the article you posted makes the case that postgres is not a good json database, because it can not modify json documents in place.

PG 9.5 will improve this situation somewhat, e.g., builtin functions like jsonb_set(), and overloading the '-' operator for jsonb values: http://www.postgresql.org/docs/devel/static/functions-json.h... That said, if you're doing a lot of mutation of large JSON documents stored in a single Postgres row value, the storage/concurrency control behavior still won't be ideal.

Actually if you really need to update large JSON documents efficiently, probably the only really efficient technology would be ToroDB http://www.8kdata.com/torodb/

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#99

Post by geedy »

I recently used Postgres for a serious project for the first time and I am really impressed. Certainly much more impressed with it than MySQL or SQL Server. plpgsql is far better than what MySQL offers out of the box, plus you have access to nicer languages out of the box with plv8, plpythonu, plr, etc. Language extensions really are a killer feature and make moving application logic into the database a cinch.

Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]

#100

Post by collyw »

baq wrote: post #71
collyw wrote: post #40

Earlier quoted context omitted.

Thats like trying to say emacs is easier than eclipse. Sure it may be more efficient once you are used to it, but its not more intuitive.

eclipse and intuitive shouldn't ever be used in the same sentence. emacs ditto, but calling one more intuitive from another is missing the point by about 1 AU.

Eclipse isn't great in that respect, but choosing something from a menu is definitely more intuitive than remembering the cryptic commands in emacs.
Post reply on HN