Well, if you’re reimplementing an existing system, you might be more comfortable emulating the known application. If I was building it from scratch, though, I’d follow something similar to the architecture I laid out.
Right now you have a separate spreadsheet per job. In the system I proposed, you’d have a separate
[Jobs] record per job. The analogy isn’t that good in either direction, but an Airtable record is structurally more kin to an Excel spreadsheet than it is to a spreadsheet row. (The spreadsheet metaphor is both blessing and curse for Airtable. On one hand, it makes it very easy to grasp the concept of Airtable; on the other, though, it can lead to a very incomplete understanding of what the product is, does, and is capable of.)
The problem with using a new table for each iteration of something (in this case, each new job) is that table creation is fundamentally a development task. That is, each time you create a new table, you have to define each field, each formula, every relationship, and so forth. In comparison, creating a new record is an organic process encountered as an unexceptional occurrence during normal operations. Each newly created record incorporates the same complement and arrangement of fields, ready to be populated without additional development required. And since each record is a discrete entity, your music video record will overlap your commercial record only as much or as little as you desire.
Again, though, ultimately the best solution is the one you’ll actually use. A higher comfort level might, in the long run, outweigh any negative effects from using a less-than-optimal architecture.