CIRCLE WITH A DOT

@amy It's not really time-dependent, I probably didn't express that well. It's more like I suspect that parts of the record might need to be updated or expanded separately in future. It's about podcasts, and my suspicion is that if a podcast feed changes, we need a mechanism by which to resolve multiple feed URLs to the same feed entity, which means storing feed URLs separately and referencing the parent record.

So it's not time so much as it is wanting to have a central resource entity then splitting up any information I know to be variable into separate records. I just want to make sure I'm A) not overcomplicating the design and B) future-proofing it in a scaleable and extensible way. I know enough to realize there might be an issue there, but not enough to know how to design the structure properly, you know?

@amy I'm designing it from scratch, and as part of that I'm thinking about the fact that there are probably places where I'm going to need to divide data up because their state changes asynchronously. That means I need to have some fundamental understanding of the best way to structure those tables, how to index them, the best way to write queries, etc. etc.

I know how to do the actual breaking up of everything and how to create indices in my code, but I'm realizing that I don't understand database systems and design well enough to make smart decisions there, you know?