3 ms·

Unfortunately I found that foreign keys in my Rails migrations were a constant source of headaches. Moreover, I decided to migrate to Heroku during the project

Unfortunately I found that foreign keys in my Rails migrations were a constant source of headaches. Moreover, I decided to migrate to Heroku during the project and had to re-write the foreign keys for Postgres instead of MySQL. What did I learn about customers in this process? Nothing. While I agree with Mr. Dewalt's basic message, identifying integrity constraints as something a "lean startup" shouldn't worry about for a production application containing his customers data undermines his implicit claim of data management competency - experienced database developers know how to design and organize their schema so that details like dbms-specific foreign key implementation are trivial. When foreign keys cause you serious pain relative to your other data management problems it means you're doing something wrong. What he didn't learn about his customers in the hour at most it should have taken him to get the keys right (thus helping ensure his customers data is not corrupted by application, framework or provider infrastructure bugs) pales in comparison to the lesson he will learn if their data is silently corrupted.

gaius 17y ago
Yep. Sure, to survive in the long term, you've got to survive in the short term first. But taking a shortcut that ultimately results in losing a customer's data (or indeed, losing track of their money or their stuff) is a bigger risk than getting your product out of the door a day late(r than you wanted).
btilly 17y ago
The initial success of MySQL is evidence against your assertion. When MySQL came out it was the first widely used database that explicitly said that speed of development and operation matters more than correctness. Experienced DBAs were shocked and horrified. Over time the database has matured, however its initial success stands as a testament to the principle that there are a lot of problems (particularly in the web area) where people care that the site does what they want and is responsive, but are tolerant of occasional problems. Yes, I am aware of all of the possible shortcomings. However requiring people with good ideas to understand more theory before they can get things done does not help motivated newcomers to get interesting things done. And lots of newcomers getting interesting things done leads to successful startups. Which is how a crappy but convenient database (MySQL) got traction in the first place. For a classic essay on the tradeoff between convenience and correctness, see Worse is Better at http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html.
- dstorrs 17y ago
  When MySQL came out it [...] said that speed of development and operation matters more than correctness. [...I]ts initial success stands as a testament to the principle that there are a lot of problems (particularly in the web area) where people [...] are tolerant of occasional problems. I wonder if this would still be true today? Things are very different from 1994, when MySQL was born. Back then, the Web was so small it was almost possible to visit every site. Site designers, site developers, and customers were all trying new things constantly and learning what worked. There weren't many expectations because everything was so new. Today, my guess is that people have a much higher standard for e-commerce. But that's just a guess.
  - btilly 17y ago
    People want to believe that their money is safe. But people are still pretty tolerant if something like twitter has an outage.
kscaldef 17y ago
What really baffled me about that anecdote is that I wonder what he was "learning about his customers" by migrating hosting providers and database systems. And yet, somehow, foreign keys get all the blame.
joe_the_user 17y ago
It seems like there are two kinds of experience. One is learning to do the same thing over-and-over again, getting somewhat better at it. This often results in being more rigid. The other is learning the purpose and strategy behind what you do and being able to alter your behavior accordingly. The often results in being more flexible. An experienced developer probably has a combination of these two ingredients. Thus there's no guarantee that an old timer will be more flexible or less flexible than a beginner. It's more a question of whether a developer has kept their learning and understanding to be at a high level. I mean, it's important to realize that the purpose of a full ACID database is to maintain the integrity of enterprise data - key data that is used and re-used by multiple departments. Of course, in a start-up, the ACID requirement can be modified depending on whatever decreased need there is for the properties of ACID. An experienced developer looking from a high level doesn't just recite ACID requirement or glibly toss them out the window but looks at the actual requirements and modifies things accordingly.

gaius 17y ago

Yep. Sure, to survive in the long term, you've got to survive in the short term first. But taking a shortcut that ultimately results in losing a customer's data (or indeed, losing track of their money or their stuff) is a bigger risk than getting your product out of the door a day late(r than you wanted).

btilly 17y ago

The initial success of MySQL is evidence against your assertion. When MySQL came out it was the first widely used database that explicitly said that speed of development and operation matters more than correctness. Experienced DBAs were shocked and horrified. Over time the database has matured, however its initial success stands as a testament to the principle that there are a lot of problems (particularly in the web area) where people care that the site does what they want and is responsive, but are tolerant of occasional problems. Yes, I am aware of all of the possible shortcomings. However requiring people with good ideas to understand more theory before they can get things done does not help motivated newcomers to get interesting things done. And lots of newcomers getting interesting things done leads to successful startups. Which is how a crappy but convenient database (MySQL) got traction in the first place. For a classic essay on the tradeoff between convenience and correctness, see Worse is Better at http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html.

dstorrs 17y ago
When MySQL came out it [...] said that speed of development and operation matters more than correctness. [...I]ts initial success stands as a testament to the principle that there are a lot of problems (particularly in the web area) where people [...] are tolerant of occasional problems. I wonder if this would still be true today? Things are very different from 1994, when MySQL was born. Back then, the Web was so small it was almost possible to visit every site. Site designers, site developers, and customers were all trying new things constantly and learning what worked. There weren't many expectations because everything was so new. Today, my guess is that people have a much higher standard for e-commerce. But that's just a guess.
- btilly 17y ago
  People want to believe that their money is safe. But people are still pretty tolerant if something like twitter has an outage.

kscaldef 17y ago

What really baffled me about that anecdote is that I wonder what he was "learning about his customers" by migrating hosting providers and database systems. And yet, somehow, foreign keys get all the blame.

joe_the_user 17y ago

It seems like there are two kinds of experience. One is learning to do the same thing over-and-over again, getting somewhat better at it. This often results in being more rigid. The other is learning the purpose and strategy behind what you do and being able to alter your behavior accordingly. The often results in being more flexible. An experienced developer probably has a combination of these two ingredients. Thus there's no guarantee that an old timer will be more flexible or less flexible than a beginner. It's more a question of whether a developer has kept their learning and understanding to be at a high level. I mean, it's important to realize that the purpose of a full ACID database is to maintain the integrity of enterprise data - key data that is used and re-used by multiple departments. Of course, in a start-up, the ACID requirement can be modified depending on whatever decreased need there is for the properties of ACID. An experienced developer looking from a high level doesn't just recite ACID requirement or glibly toss them out the window but looks at the actual requirements and modifies things accordingly.