Uuh, what’s the issue with using pg_dump for backing up? Aside from it not being incremental, of course.
I’d also be interested in the answer to this, in addition to why one shouldn’t put a database and it’s follower on separate hardware?
I think he means things like potentially different architecture but also probably things like different sized disks or amounts of ram.
I think what it means is use different hardware architectures? I’m not sure how else to interpret that.
Oh boy, that was a great slide deck :-)
I remember I was aghast at finding, in my first job, that our sessions table did not have a unique constraint on the user id column. The code tried, in various places, to avoid inserting multiple sessions for people, but I know it wasn’t successfull because it was part of my job (doing technical support) to help debug users' mystifying issues due to them having two or three sessions at once. I was not allowed to eliminate these problems by making the user id unique, because as the founder argued, “unique indexes makes inserts slow”. This was MySQL, back in the bad old 3.17 days, so he might have had a point—but I feel confident to this day that none of our 500 users would have noticed. (Based on the observation that we truncated the sessions table every night, and the auto-incrementing primary key rarely went into four digits during the day.)
Not agree with ORM. I’m so glad to use ActiveRecord or Ecto and not write all the SQL. I find it easier to reeuse (scope), more secure (http://rails-sqli.org/), easier for new comers and more consistent accros project.
That’s all convenient until you need to use things like PostGIS or another non-lowest-common-denominator piece of database functionality, or deal with performance issues.
This is beautiful.