LinkedinLunatics

3580 readers

61 users here now

A place to post ridiculous posts from linkedIn.com

(Full transparency.. a mod for this sub happens to work there.. but that doesn't influence his moderation or laughter at a lot of posts.)

founded 1 year ago

MODERATORS

[email protected]

328

Belching (sopuli.xyz)

submitted 4 months ago by [email protected] to c/[email protected]

80 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 125 points 4 months ago (6 children)

One of the reasons women will find this repugnant is because they didn't normalize their tables. Should be boyfriend_id is null.

[–] [email protected] 77 points 4 months ago (3 children)

For that matter, why is waist size a Boolean?

[–] [email protected] 66 points 4 months ago (1 children)

They allowed business logic to pollute the DB table, and "small waist" is a defined range in some confluence doc somewhere.

[–] [email protected] 4 points 4 months ago (1 children)

Or this is an analytics database where these are well-defined dimensions added for segmentation logic. 🤷

[–] [email protected] 4 points 4 months ago

The dream

[–] Huschke 12 points 4 months ago

And why is cuteness and craziness binary?

[–] JackbyDev 24 points 4 months ago (2 children)

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)?

[–] [email protected] 9 points 4 months ago (2 children)

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

[–] [email protected] 3 points 4 months ago (1 children)

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?

[–] [email protected] 2 points 4 months ago* (last edited 4 months ago)

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.

[–] JackbyDev 1 points 4 months ago

To that point a person table with a relationship table. [...] 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.

Yeah, that's how many to many relationships work. Especially if you care at all about normalization which I assume we do since we're debating the best way to model a SQL joke on a tee shirt lol. I thought this might be common knowledge but I've included a few links in case you're curious. Many-to-many relationships

Also, a table having a many-to-many relationship with itself isn't terribly special. It's just not necessarily the most common thing ever. We can even express love triangles (as in unrequited love) using this approach. Proper couples could have two entries but unrequited ones would only have one entry on the junction table.

Also a relationship table would allow exploring other types of relationships such as exes, love interests, coworkers, family, friends, etc

Yes! Absolutely! You could have a column that describes the type of the relationship. Having extra information on junction tables.

[–] [email protected] 3 points 4 months ago

I guess everyone sets up their own tables.

[–] [email protected] 10 points 4 months ago

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...

[–] [email protected] 3 points 4 months ago

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.

[–] [email protected] 2 points 4 months ago (1 children)

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.

[–] [email protected] 1 points 4 months ago

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.

[–] [email protected] 1 points 4 months ago (1 children)

Are you really doing relational data if it has nulls though?

[–] [email protected] 1 points 4 months ago

Yes.