Why we lost Uber as a user

Post by rlpb » Mon, Aug 01, 2016, 12:49 PM UTC

babuskov wrote: post #28

matthewmacleod wrote: post #11

The PoststgreSQL project never fails to impress me. I know that there are some use cases which are not currently covered by it versus alternatives, but I have consistently got the feeling that everybody involved in the project is supremely professional and interested in building an excellent database – and the focus is on how to work to fix these use cases, instead of pointless mudslinging. Class act.

> The PoststgreSQL project never fails to impress me. Except the name is a bit clunky and hard to write ;)

Post by [deleted] » Mon, Aug 01, 2016, 12:52 PM UTC

LeifCarrotson wrote: post #41

rimantas wrote: post #21

but have you used MySQL? Maybe I am too nitpicky, but I always get suspicious when people make claims about technology whose name they cannot spell right.

In this case, Fabian's CV (linked from his GitHub profile, linked from his HN profile) does claim MySQL experience - correctly capitalized. But yes, I also get suspicious when people can't spell a technology correctly. For example, anyone who has spent time reading some documentation will know that Lua is capitalized in title case, and not written LUA.

Post by kstenerud » Mon, Aug 01, 2016, 12:52 PM UTC

LeifCarrotson wrote: post #41

rimantas wrote: post #21

but have you used MySQL? Maybe I am too nitpicky, but I always get suspicious when people make claims about technology whose name they cannot spell right.

In this case, Fabian's CV (linked from his GitHub profile, linked from his HN profile) does claim MySQL experience - correctly capitalized. But yes, I also get suspicious when people can't spell a technology correctly. For example, anyone who has spent time reading some documentation will know that Lua is capitalized in title case, and not written LUA.

Post by zspitzer » Mon, Aug 01, 2016, 12:53 PM UTC

dagss wrote: post #29

mnw21cam wrote: post #18

Earlier quoted context omitted.

That kind of thinking is probably what spawned the whole "do the join in the app, not the database" anti-pattern. The truth is, the database is going to be much faster at performing a join than loading the contents of two tables into your app and iterating. If you need the data that results from doing a join, doing a join is the best way to get it. Unless you already have your entire database in-memory in your app, t…

What you are missing here is "denormalization" -- e.g. many-to-many relationships. You can either use a JOIN with a table on a "normalized" database, or keep managing the result of the join in application code. Loading the entire tables into application code very seldom has anything to do with it... A more realistic example is, do you get Alice's pets by doing a JOIN on tables Person, Pet, PetOwnedByPerson ("SQL") --…

Post by mixedCase » Mon, Aug 01, 2016, 12:55 PM UTC

landmark3 wrote: post #60

one other reason is that postgresql.org forum comes straight from 1984