Skip to content

Conversation

@pushcx
Copy link

@pushcx pushcx commented Mar 25, 2013

I happened across this repo from Jeremy Merrel's war story about "Dollars for Docs". After scraping and building news stories at the Post I had a couple tips to offer, please feel free to use or ignore as you see fit.

I happened across this repo from Jeremy Merrel's war story about "Dollars for Docs". After scraping and building news stories at the Post I had a couple tips to offer, please feel free to use or ignore as you see fit.
_Peter Harkins, formerly of the Washington Post on structuring data:_

- Extract real data (choose the worst, noisiest stuff) to use as fixtures in automated tests and you'll know you haven't broken things as you go.
- Don't model anything as many-to-many. Name the intermediate concept and give it two one-to-many associations. It will almost always want to accumulate more info in the future, and the cost of changing your model will be high.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I fully understand this point. In what situation would a many-to-many relationship not have an intermediate table / linking vehicle like you describe?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will have to have an intermediate table, but I'm saying that intermediate table must be considered an entity in its own right. For instance, if you link authors and screenplays in Rails it'll call the join table authors_screenplays. Don't do that, name it authorships, model it, and treat it as a first-class record rather than plumbing. It will certainly gain complexity over time, and the longer you go before recognizing the relationships as a record, the more pain your code will suffer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants