4 ms·
> 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
by polote 6y ago
> 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?
- jrvarela56 6y agoSRP, makes it easier to test a unit if you know there's a specific/small dependency between the big model and the new small model. Also makes it easier to understand by giving a set of fields a name, sort of like a summary.
- tarkin2 6y agoAgree. It also makes for a sql table explosion.
- mushishi 6y agoJust a thought when it might be viable: if a subset of that table receives a lot of updates, and it would be helpful to your access patterns if some of it was separated into a different table that was rarely updated but accessed a lot?
- vangelis 6y agoIt depends on your usage. Sometimes denormalization is what you need.
- nitely 6y agoAdding unnecessary joins.
- GauntletWizard 6y agoHere’s a good example of 1:1 denormalization: Say I’m running a music streaming service. I can store my music tracks as a giant database of MP3s, ID3 tags included, and parse out each ID3 tag on each read. I could, alternatively, store the music tracks as a giant database of music tracks, which has “Artist”, “Album”, etc. fields, and one field for “MP3” that contains no id3 tags. Both are “normalized” data structures. Storing the id3 tags with the MP3 would be denormalization. It might be much saner to do that than to reconstruct them every time someone goes to download them. 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.
- nicbou 6y agoBesides, you can simplify the Python side of things without touching the database side of things with mixins.