Two years ago I switched from PHP and MySQL to Ruby and PostgreSQL. The only thing I'm missing is Sequel Pro. PG Admin is ok, does everything I need, but that interface is ugly and unintuitive. [1] http://www.sequelpro.com/
Have been using postico https://eggerapps.at/postico/ for day to day queries and pgadmin for more hardcore operations
“Fashion Is Hard. PostgreSQL Is Easy” [video]
111–120 of 140 posts
Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]
#112I 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…
"Stored procedures for everything" is a bit unorthodox, but its probably a better practice that "base tables for everything" (which seems to be the common trend these days), and is pretty much the closest real practice to the "views for everything" that was long the ideal for decoupling decoupling the interface that each component using the DB saw from the underlying data model (an ideal that was, when it was made, o…
Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]
#113Earlier quoted context omitted.
As someone who's used to MySQL, I keep trying to use PostgreSQL (better standards compliance, better behaviour in the face of bad data) - and I keep going back. The psql interface is awkward (too many magic backslash commands to memorize instead of SHOW CREATE TABLE) and always feels slightly laggy somehow.
You are the first person I read saying they like the mysql cli. Ctrl-c kills the whole shell. great, but not what I expect. Want to fix a small typo in your big query? In psql you can just edit your last command in your $EDITOR. Useful (but not perfect) autocomplete is also not in mysql.
Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]
#114Earlier quoted context omitted.
Count another vote for the pgadmin. I hate the backslash commands of postgres, about as much as I hate the show commands of mysql (what's not nearly as much as I hate the oracle introspection tools). Why couldn't SQL standardize database introspection?
it did. https://en.wikipedia.org/wiki/Information_schema
Thanks.
Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]
#115Earlier quoted context omitted.
In MySQL type \e and you can edit your query just the same. https://dev.mysql.com/doc/refman/5.6/en/mysql-commands.html
I love that earlier up in this same thread people are complaining about the magic \x sequences in postgres and this is how you do query edits in the mysql cli :) I've got my biases, but whenever something like this comes up, I just make some popcorn and enjoy the show.
In MySQL the backslash sequences are commands to the mysql client for things that are implemented in the client and have to do solely with the command line client software. These things are not available using other clients. Vs things like listing columns and databases and functions have their own DDL language constructs entries and are queries in their own right that can be sent by any client software to the server and return iteratable results. MySQL is more like Oracle in this regard.
That distinction isn't obvious in psql and that contributes to a larger hurdle when using the command line client. This makes psql attractive to power users, as there are a lot of shortcuts for things that might require longer DDL statements to be typed or queries against information_schema.
Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]
#116Two years ago I switched from PHP and MySQL to Ruby and PostgreSQL. The only thing I'm missing is Sequel Pro. PG Admin is ok, does everything I need, but that interface is ugly and unintuitive. [1] http://www.sequelpro.com/
Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]
#117Earlier quoted context omitted.
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]
#118Earlier quoted context omitted.
Count another vote for the pgadmin. I hate the backslash commands of postgres, about as much as I hate the show commands of mysql (what's not nearly as much as I hate the oracle introspection tools). Why couldn't SQL standardize database introspection?
This whole thread makes me happy to be a SQL Server user, where the UI tools are standard and robust. 90% of the time, I don't need to remember any special commands for introspecting and since it's on Windows - I can use the keyboard to navigate the entire UI with ease. When I write SQL, I get glorious Intellisense (that's autocomplete to you) for every single object ( edit: and command ) in the db.
Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]
#119Earlier quoted context omitted.
That's probably the best way of looking at it. PostgreSQL is generally going to be the best solution for 90% of your data, short of having a subset that's write heavy to the point of streaming.
What is a good space to look at when you get write heavy data to the point of streaming?
Re: “Fashion Is Hard. PostgreSQL Is Easy” [video]
#120I 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…