5 ms·

> Why was -- in this contrived scenario -- Jack's solution a "maintenance nightmare"? Just because. Because apparently the author didn't have the necessary ski

> Why was -- in this contrived scenario -- Jack's solution a "maintenance nightmare"? Just because. Because apparently the author didn't have the necessary skills to maintain it. Cassandra isn't easy to master, especially if you only have cheapo developers who are reluctant to switch to PostgreSQL from MySQL. But yes, it's a highly opinionated, narrow-minded piece.

mtrimpe 13y ago
Whenever somebody lists the traits of great developers the number one trait is invariably: "They're like me." I'll cut the author some slack here though since the article is over two years old by now.
Pxtl 13y ago
Having only used Oracle, MSSQL, and MySQL, I can't imagine a small 500-user app would be that hard to implement in in Postgre even if I'd never touched the platform before - does Postgre have some terrifying gotchas, or does it work as a reasonably well-behaved SQL server? That is, if I naively installed a PostgreSQL server on my box and started creating tables and indexes and users, would I be destroyed by some horrible gotcha as I failed to account for some critical config (like selecting the right storage engine in MySQL)?
- skyebook 13y ago
  As someone who moved from MySQL to Postgres, the only thing that took some getting used to was users being actual Unix users that you create and then grant access to. At the time it seemed odd considering what MySQL did but it ended up being a feature I like quite a bit.
  - fusiongyro 13y ago
    PG roles are stored in the DB, not Unix. You can set up pg_hba to use ident authentication so that users are automatically granted access by their Unix login, but it isn't the default (and usually not recommended), and you still have to have PG roles in the database for them to correspond to. So I think there's been a misunderstanding.
- pnathan 13y ago
  It's my understanding that there are no config gotchas in PostgreSQL (unlike MySQL). I've definitely found it more of a pain to set up at first. This is because the default role is very restricted and defaults to safe.
- Xylakant 13y ago
  They're similar, but there are some pitfalls you need to be aware of: count(*) optimisation in mysql for example. Different behaviour in the query optimiser. Most cases are easy to handle, but if you're used to mysql, there's still a learning curve.

mtrimpe 13y ago

Whenever somebody lists the traits of great developers the number one trait is invariably: "They're like me." I'll cut the author some slack here though since the article is over two years old by now.

Pxtl 13y ago

Having only used Oracle, MSSQL, and MySQL, I can't imagine a small 500-user app would be that hard to implement in in Postgre even if I'd never touched the platform before - does Postgre have some terrifying gotchas, or does it work as a reasonably well-behaved SQL server? That is, if I naively installed a PostgreSQL server on my box and started creating tables and indexes and users, would I be destroyed by some horrible gotcha as I failed to account for some critical config (like selecting the right storage engine in MySQL)?

skyebook 13y ago
As someone who moved from MySQL to Postgres, the only thing that took some getting used to was users being actual Unix users that you create and then grant access to. At the time it seemed odd considering what MySQL did but it ended up being a feature I like quite a bit.
- fusiongyro 13y ago
  PG roles are stored in the DB, not Unix. You can set up pg_hba to use ident authentication so that users are automatically granted access by their Unix login, but it isn't the default (and usually not recommended), and you still have to have PG roles in the database for them to correspond to. So I think there's been a misunderstanding.
pnathan 13y ago
It's my understanding that there are no config gotchas in PostgreSQL (unlike MySQL). I've definitely found it more of a pain to set up at first. This is because the default role is very restricted and defaults to safe.
Xylakant 13y ago
They're similar, but there are some pitfalls you need to be aware of: count(*) optimisation in mysql for example. Different behaviour in the query optimiser. Most cases are easy to handle, but if you're used to mysql, there's still a learning curve.