Alternative to "master" and "slave" in entity relationship?

Example: I have two tables in my database called classA and classB, and one table called classA_classB. The last one just defined two int fields with foreign keys to link between classA and classB. So one classA can have many classB, and many classA can link with the same classB. Simple stuff, so far.

The problem is, in my special case, that I have a classA which wants to link to another classA. I.e. a Student links to his friends, who are Students as well.

So analogue to the technique above, I have: student and student_student. student_student has two fields: student_id, student_id. Problem: Can't have two fields with same name!

So I must call them like: master_student_id, slave_stude开发者_如何学运维nt_id.

But I don't like the terms "Master" and "Slave", because these are reminders to a bad time in our pasts. It may sound silly but I think it's not correct to keep these, at least from a moral perspective. I know it's just a part of modern computer science,... but....

how else could I call them?

parent and child maybe? Also i'm not sure if there's really one entity "the chief" while the other is "the employee"... Student and Student are not hierarchical. But then, again, lets imagine we had two classes "Teacher" and "Student". That would be a clear hierarchy. However, I need a neutral solution because my framework threads these 1:n relationships allways the same way.

---

Parent and Child or Owner and Child is the generally accepted solutions.

---

the industry standard nowadays seems to be {master-follower}

see the following references:

[01]
www.mchotline.com/Reference/MN20B302.pdf

[02]
www.ab.com/linked/drives/drvappsw/files/AppSets_PF700S/AS_PF700S_VirtEncdr_PositMaster_SL.pdf

[03]
www05.abb.com/global/scot/scot201.nsf/veritydisplay/bd987cd590c931fcc1257249003d8f4f/$file/factfile_master_follower_pd11_lowres.pdf

[04] www05.abb.com/global/scot/scot201.nsf/veritydisplay/a11e30d538ab1b49c2256def00493279/$file/en_800stdprg_mfguide_a.pdf

[05] www.danfoss.com/BusinessAreas/DrivesSolutions/MUSEC/

[06] forums.ni.com/t5/Motion-Control-and-Motor-Drives/Converting-a-master-follower-type-Cam-Grinding-Machine-to-CNC/td-p/1469070

[07] www.burhansresearch.com/mrcwfdbk1.htm

[08] www.eurekamagazine.co.uk/article/28893/Master-follower-communication-in-ABB-industrial-drives.aspx

[09] www.lockmasters.com/index.asp?PageAction=VIEWPROD&ProdID=49879

[10] www.perfusion.com/cgi-bin/forum/forum_posts.asp?TID=500

this also makes more sense - no need to employ a morally reprehensible term for a hierachical computer/technological controls arrangement... for example, we would designate connectors as "male" and "female", not "male" and "whore".... both cases "make the point" in a somewhat descriptive sense, however it is best to make the point using non morally reprehensible or inflammatory terms

excellent question, btw!

---

there appear to be 3 competing industry alternatives to master/slave. they are:

• Master/Follower
• Parent/Child
• Primary/Secondary

I think primary/secondary is weird because we could have multiple secondary. I feel like after secondary would be tertiary, quaternary, etc. Too much of a pain.

Master/Follower still has vague slavery/feudalism connotations.

That leaves us just with Parent/Child... but I don't really like that because Child sounds incapable, but there are some cases where we'll depend on the Child, not the Parent....

SO, I'm going to suggest yet another combo here:

• Primary/Alternate

That naming should avoid any slavery, gender, and plurality issues.

---

How about student_id and friend_id? There's no rule that says your foreign keys need to have the same column names as the primary key.

---

related_id or associated_student_id would be my preference.

---

{master-follower} instead of {master-slave}

---

What are the roles of the two students in the relationship? Friends? Mentors? Acquaintances? There are lots of possible roles they fill.

You can brainstorm a lot of roles that have asymmetric names.

friend, friend_of

mentor, mentored_by

referrer, referred_by

---

Depends on whether or not the relationship (lets call it R) is symmetric. If so then person1, person2 is fine since R(person1, person2) = R(person2, person1). If they are not symmetric then the names should probably reflect an "agent and patient" relationship. So use a word to denote the agent and one to denote the patient, e.g. Befriender, Friend.

---

I found myself in this dilemma too. Thanks for asking the question.

I'm in a cluster, so we preferred:

• slave -> node
• master -> coordinator

That's a lot better.

EDIT: It is important to note for example that other projects have updated its policies, recently the Linux kernel documentation got update with this. Citing:

For symbol names and documentation, avoid introducing new usage of
'master / slave' (or 'slave' independent of 'master') and 'blacklist /
whitelist'.

Recommended replacements for 'master / slave' are:
    '{primary,main} / {secondary,replica,subordinate}'
    '{initiator,requester} / {target,responder}'
    '{controller,host} / {device,worker,proxy}'
    'leader / follower'
    'director / performer'

Recommended replacements for 'blacklist/whitelist' are:
    'denylist / allowlist'
    'blocklist / passlist'