You're viewing a single thread.
One of the reasons women will find this repugnant is because they didn't normalize their tables. Should be
boyfriend_id is null.For that matter, why is waist size a Boolean?
They allowed business logic to pollute the DB table, and "small waist" is a defined range in some confluence doc somewhere.
Or this is an analytics database where these are well-defined dimensions added for segmentation logic. 🤷
The dream
And why is cuteness and craziness binary?
Why is there a separate table for men and women in the first place? Shouldn't there be a person table with a many to many relationship with itself (because polyamory exists)?
To that point a person table with a relationship table. So this way you can reference relationship between two or more persons within the relationship table and that could be joined to the person table if needed. I don't think you'd really be able to keep it within one table while exploring multiple relationships unless you're storing a list of ids that is interpreted outside of sql. Also a relationship table would allow exploring other types of relationships such as exes, love interests, coworkers, family, friends, etc
Yeah it'd be a person table, and the relationship table indicating the ids of shipped couples. Do you think there'd need to be a status in the relationship table so we can tombstone exes? Or maybe started and ended date columns for each relationship so we can figure out whose cheating on who. But when about on-off relationships then? How would we model Ross and Rachel?
I think wed just need the following
- rel.id (primary key)
- rel.user_id (foreign key to person.id)
- rel.user_id2 (foreign key to person.id)
- rel.type (type of relationship)
- rel.start (non null)
- rel.end
From there you don't need a rel.status because you're not updating this rel.id entry except for the rel.end. if they started dating again later it would be a whole new entry, and then you could query their entire dating history to see if they keep coming back to the same person, dating around, playing the field, etc. Separately there could be a friendship relationship that is tracked so you could if they ended being friends after a breakup.
I guess everyone sets up their own tables.
Or, if you allow for polyamory and non-hetero relationships, you probably need a rel table (and some joins in the query).
Maybe GIRLS is just a view...
Maybe it's supposed to imply that boyfriend is an attribute of the particular girl. Like saying she isn't someone's boyfriend. It's probably a holdover from the original data architecture and nobody ever bothered to modify the table later on in case there's a select somewhere that expects that field to exist.
That structure doesn't handle polyamorous and cheating relationships very well. It should probably have
and (select top 1 1 from dbo.relationships r where r.partner_a != GIRLS.id or r.partner_b != GIRLS.id)which would handle also LGBT+ relationships or relationships that are better represented as a graph.The relationships table should also have enum for relationship type. It might be friends, family, platonic relations etc. Also might want to check sex_drive to handle ace gals and something to do with kinsey scale not to bother lesbians.
Are you really doing relational data if it has nulls though?
Yes.