5 ms·

I was expecting OP to keep blaming database choice given that their opinion on decision making is critical. But they seem to give lots of praise to the database

I was expecting OP to keep blaming database choice given that their opinion on decision making is critical. But they seem to give lots of praise to the databases full text search features. Appearantly he was judging Heroku's choice of database, which I guess would not be a random one. Can not grasp the incentives of why it is put like that in the article. Though dramatizing is a nice contour to have but gives away prejudice bias, as this comment does for me.

hardlianotion 3y ago
He wasn’t criticising Heroku’s choice. He was critical of the contract developers’ lack of critical thought when adopting the Heroku default.
- relix 3y ago
  (not a rebuttal on your comment, just a continuation of the conversation) I found it an interesting criticism, and from what we know about the project I don't think I agree with the author. In the space of what database to use, there are really few differences between Postgres and Postgres' peers, that "using what's available" is a perfectly sound reasoning to use Postgresql over, say, MySQL. I think around that time MongoDB was a possible alternative as well, however it was experimental and often mocked. Postgres and Mysql are pretty much feature parity, even in 2011, except for very niche use cases, which this project did not sound like it would have. Factoring in that Heroku's PG UI is great, and to use an alternative would mean to have to set things up yourself (in 2011 the Heroku marketplace was not yet as expansive iirc), or at least have another account at another SaaS company with dubious maturity, the decision to use PG seemed to have been given the correct amount of critical thinking ("will it be able to support all that we need? most likely yes"). The author may also not have been aware that for RoR applications the code is pretty DB-agnostic, an unawareness he hints at in other parts of the story as well. Meaning that in the span of the year that they're working on rebuilding the site in RoR, if they discover a use case that another DB would be extremely helpful with, they could relatively easily switch over to this other DB without having to rewrite all of the code. At most it'd take rewriting of some migrations for FK's and possibly some (hopefully few) custom SQL queries. Remember that they had a one-time-switch-over when the site was done being built, so during this year of development time, the database did not accrue live user data that would have made such a change more difficult.
  - brightball 3y ago
    Just to clarify a bit: https://news.ycombinator.com/item?id=36030033 https://news.ycombinator.com/item?id=36030033 You’re not wrong in your assessment but I would still expect a company architecting a total replacement for an existing system to know why they are choosing critical components. In this case it was an extensive lack of database consideration in many decisions.
    - relix 3y ago
      The extensive lack of database consideration in many decisions is indeed concerning, and obviously integrity checks should be standard and default.
    - spiffytech 3y ago
      In my mind, the distinction is whether the decision was thoroughly considered. Contrast these two attitudes: "PG is a common choice, which is valuable. We understand our requirements and options well enough to consider it appropriate." vs: "PG is the one we've heard of, why would we look at anything else?"
brightball 3y ago
Audience for the post matters too. Much of this and the supporting articles were focused on the security and fraud topics. Since those details were linked out from this article, most of what's left is around the technical bits that didn't get their own posts. For an audience of programmers on HN, I'm not surprised that this topic got more attention than the fraud but it definitely wasn't intended to be the focus of the post.
- simultsop 3y ago
  Since fraud is a broad problem to tackle with and it requires individual awareness. It challenges densely education of the users rather than technical enhancement which ends up on OTP and 2FA. Honesty of the point of view of OP is the most attractive part of the article which leads one to complete reading. Then focus on the domains varies on readers interests to discuss.

hardlianotion 3y ago

He wasn’t criticising Heroku’s choice. He was critical of the contract developers’ lack of critical thought when adopting the Heroku default.

relix 3y ago
(not a rebuttal on your comment, just a continuation of the conversation) I found it an interesting criticism, and from what we know about the project I don't think I agree with the author. In the space of what database to use, there are really few differences between Postgres and Postgres' peers, that "using what's available" is a perfectly sound reasoning to use Postgresql over, say, MySQL. I think around that time MongoDB was a possible alternative as well, however it was experimental and often mocked. Postgres and Mysql are pretty much feature parity, even in 2011, except for very niche use cases, which this project did not sound like it would have. Factoring in that Heroku's PG UI is great, and to use an alternative would mean to have to set things up yourself (in 2011 the Heroku marketplace was not yet as expansive iirc), or at least have another account at another SaaS company with dubious maturity, the decision to use PG seemed to have been given the correct amount of critical thinking ("will it be able to support all that we need? most likely yes"). The author may also not have been aware that for RoR applications the code is pretty DB-agnostic, an unawareness he hints at in other parts of the story as well. Meaning that in the span of the year that they're working on rebuilding the site in RoR, if they discover a use case that another DB would be extremely helpful with, they could relatively easily switch over to this other DB without having to rewrite all of the code. At most it'd take rewriting of some migrations for FK's and possibly some (hopefully few) custom SQL queries. Remember that they had a one-time-switch-over when the site was done being built, so during this year of development time, the database did not accrue live user data that would have made such a change more difficult.
- brightball 3y ago
  Just to clarify a bit: https://news.ycombinator.com/item?id=36030033 https://news.ycombinator.com/item?id=36030033 You’re not wrong in your assessment but I would still expect a company architecting a total replacement for an existing system to know why they are choosing critical components. In this case it was an extensive lack of database consideration in many decisions.
  - relix 3y ago
    The extensive lack of database consideration in many decisions is indeed concerning, and obviously integrity checks should be standard and default.
  - spiffytech 3y ago
    In my mind, the distinction is whether the decision was thoroughly considered. Contrast these two attitudes: "PG is a common choice, which is valuable. We understand our requirements and options well enough to consider it appropriate." vs: "PG is the one we've heard of, why would we look at anything else?"

brightball 3y ago

Audience for the post matters too. Much of this and the supporting articles were focused on the security and fraud topics. Since those details were linked out from this article, most of what's left is around the technical bits that didn't get their own posts. For an audience of programmers on HN, I'm not surprised that this topic got more attention than the fraud but it definitely wasn't intended to be the focus of the post.

simultsop 3y ago
Since fraud is a broad problem to tackle with and it requires individual awareness. It challenges densely education of the users rather than technical enhancement which ends up on OTP and 2FA. Honesty of the point of view of OP is the most attractive part of the article which leads one to complete reading. Then focus on the domains varies on readers interests to discuss.