{"action":"created","issue":{"url":"https://api.github.com/repos/BurntSushi/nfldb/issues/77","labels_url":"https://api.github.com/repos/BurntSushi/nfldb/issues/77/labels{/name}","comments_url":"https://api.github.com/repos/BurntSushi/nfldb/issues/77/comments","events_url":"https://api.github.com/repos/BurntSushi/nfldb/issues/77/events","html_url":"https://github.com/BurntSushi/nfldb/issues/77","id":53148773,"number":77,"title":"projections database add-on","user":{"login":"hsharrison","id":4441865,"avatar_url":"https://avatars.githubusercontent.com/u/4441865?v=3","gravatar_id":"","url":"https://api.github.com/users/hsharrison","html_url":"https://github.com/hsharrison","followers_url":"https://api.github.com/users/hsharrison/followers","following_url":"https://api.github.com/users/hsharrison/following{/other_user}","gists_url":"https://api.github.com/users/hsharrison/gists{/gist_id}","starred_url":"https://api.github.com/users/hsharrison/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hsharrison/subscriptions","organizations_url":"https://api.github.com/users/hsharrison/orgs","repos_url":"https://api.github.com/users/hsharrison/repos","events_url":"https://api.github.com/users/hsharrison/events{/privacy}","received_events_url":"https://api.github.com/users/hsharrison/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":29,"created_at":"2014-12-30T21:30:26Z","updated_at":"2015-01-07T23:11:41Z","closed_at":null,"body":"Hey, thanks for this awesome library. I've been thinking of starting a new project, something similar to this but for keeping track of experts' projections.\r\n\r\nI just thought I'd ask for advice, as I'd want it to integrate with `nfldb`--at least key off of game ID and player ID. But how tight is the question. Are things going to screw up if I had more tables to the database? And how hard would it be to leverage the query system as well? Appreciate any thoughts you might have.\r\n\r\nAs for how to make it available, I think the best option is a separate package with a dependency of `nfldb`. But if you think it would make more sense as a pull request, or even a fork, let me know."},"comment":{"url":"https://api.github.com/repos/BurntSushi/nfldb/issues/comments/69109700","html_url":"https://github.com/BurntSushi/nfldb/issues/77#issuecomment-69109700","issue_url":"https://api.github.com/repos/BurntSushi/nfldb/issues/77","id":69109700,"user":{"login":"BurntSushi","id":456674,"avatar_url":"https://avatars.githubusercontent.com/u/456674?v=3","gravatar_id":"","url":"https://api.github.com/users/BurntSushi","html_url":"https://github.com/BurntSushi","followers_url":"https://api.github.com/users/BurntSushi/followers","following_url":"https://api.github.com/users/BurntSushi/following{/other_user}","gists_url":"https://api.github.com/users/BurntSushi/gists{/gist_id}","starred_url":"https://api.github.com/users/BurntSushi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/BurntSushi/subscriptions","organizations_url":"https://api.github.com/users/BurntSushi/orgs","repos_url":"https://api.github.com/users/BurntSushi/repos","events_url":"https://api.github.com/users/BurntSushi/events{/privacy}","received_events_url":"https://api.github.com/users/BurntSushi/received_events","type":"User","site_admin":false},"created_at":"2015-01-07T23:11:40Z","updated_at":"2015-01-07T23:11:40Z","body":"I absolutely think you should go with your intuition. I'm not happy with any solution I've ever come up with---I'm just tossing out ideas. :-)\r\n\r\n> Just curious, what's the rationale? A pro seems to be that I could then split the offensive statistics from the defensive categories. The con is that queries become a lot more complicated if one is interested in fantasy points across all \"positions\".\r\n\r\nThat second point is precisely the issue. If you split them, then running one query to grab everything is going to be difficult (so I agree with you there). It may be much easier to say, \"If you want projections for individual players, then write this kind of SQL. And if you want projections for defensive teams, then write this kind of SQL.\" If you end up developing a library or a UI around this stuff, *that's* where you might be able to merge them under one common interface.\r\n\r\nYour idea of using one id column to store *either* a player id or a team id is interesting. You're right to point out a foreign key problem. Maybe you just don't use a foreign key for that column?\r\n\r\nAnother option is for each of your projection tables to have two columns: `player_id` and `team_id` with the invariant that exactly one of them must always be `NULL`.\r\n\r\nI really don't see a clear answer here. I'd suggest trying both and see which one works out better. :-)"}}