3 ms·
It's easy to get up to quite a high number of joins if you have a well normalised database that uses a lot of lookup/reference tables. Common in a situation wh
by beachy 2y ago
It's easy to get up to quite a high number of joins if you have a well normalised database that uses a lot of lookup/reference tables.
Common in a situation where you're writing for a presentation layer and you need human readable data.
30 sounds a lot, but I'm pretty sure I've written SQL with almost 20 while building an ERP application so I don't see why 30 implies garbage schema, just a complex one.
And as you say, it shouldn't be a problem anyway, there no magic number of joined tables where things stay breaking down.
- SJC_Hacker 2y ago> Common in a situation where you're writing for a presentation layer and you need human readable data. Yup, this was it. For compactness (theoretical) alot of the fields were stored as small integers, then a lookup. Here is the relevant offender if interested. https://github.com/praphael/baseball/blob/main/retrosheet_init_db.py#L1274 https://github.com/praphael/baseball/blob/main/retrosheet_in... Alot of lookup for player names and more descriptive fields (field conditions, play descriptions, etc.) In retrospect, this all could have been done as part of a post-process step on the backend. I already was doing that for certain fields such as the month. Which does fail the "anything that can be reasonably be done on the DB end should be done by the DB" test. But it might be a better idea.