> A taller Model with many fields [...] It may be time to split the Model into multiple Models with a OneToOne relationship.
Never understood that advice, what's the point of complexifying your model because a class has too many attributes?
Never understood that advice, what's the point of complexifying your model because a class has too many attributes?
For performance, though - You want to store the MP3s in their own table, or not even in a “table” but as a blobstore. Storing the MP3 files for your tracks inline is entirely feasible. 3-10MB inline blobs will work in your modern database engine of choice, and simplify a lot - But you’ll often want to write your presentation layer with “SELECT * FROM tracks” - And you can do that if you just store the data blob separately; i.e. denormalize.
If you have hundreds of fields on a record, selecting from the subset that are actually relevant is far, far saner. Particularly when a large group can be nullable, and will likely be nullable together. If 10% of your business is washers - Washers of every shape, thickness, hole-size, material, etc. - You will have all of those attributes in your parts database. It’s best to treat those as first-class citizens, but they belong in a nullable 1:1 relationship.
Also makes it easier to understand by giving a set of fields a name, sort of like a summary.