I follow SvN. I'm not entirely sure why at this point, as I very rarely actually see anything of merit on it anymore, but I've not gotten disappointed enough to drop it from my Google Reader.
Yesterday the Basecamp team decided to pat themselves on the back for allowing movement of items in between projects.
I look at the list of super-duper extra hard stuff that's going on, and I see one of two cases that could possibly be true:
- They've sharded their databases to the point that even trivial operations require superhuman effort. Well-done in that case.
- They've designed their database schema in the most completely insane way ever.
My suspicions? A little of column A, a little of column B.
Love this gem:
Is it a to-do list? It might contain to-do items that have associated time tracking entries. Move those time entries to the destination project too.
That seriously doesn't flow for free due to the relational semantics? You don't just have a FK relationship that means you're only updating the list?
Here's the lessons I think everybody should learn from this:
- Sharding MySQL or another low-end relational database isn't a panacea, no matter how much it contributes to the web-scale secret sauce.
- If you are sharding/partitioning data, you should probably think long and hard in advance about how that's going to impact movements across shards. Because they ALWAYS end up happening.
Posts
