You’re right, the “follower” word does not show our intention. I used @hubertlepicki 's terms to avoid confusions, in case someone else also needs something like this.
max4all
OvermindDL1
I often do have extra data, but I still do not use an ID on those as those association tables require their 1/2/3 linked tables, so I have those foreign keys as a combined primary key as they ‘are’ the primary key lookup of these tables. Actually very few of my current models have ID’s at all (interfacing between different DB types makes things odd).
I always encode the data in the parameters, so if I wanted to, say, delete all Followings of a person then I’d have something like DELETE /user/:uid/followings, or to delete a specific following I’d do DELETE /user/:uid/followings/:following_id and that would look up the user, the user they are following, and delete the join row between them. (or ignore looking them up for validity and just delete a join column with those two ID’s if it exists at all).
2
andre1sk
Having and ID is often useful if you have a more complex stack (have a caching layer) and it’s nicer to have a simple ID vs some IDs being compound and some not.
1
OvermindDL1
Would you have cases where you would access such a join table without knowing one or both of the linked tables? I’ve not had that yet myself.
1
hubertlepicki
I will have to agree with you after giving it some more thought. The ID on the join table is because I’ve been taught to do so by ActiveRecord. There is nothing on the database level that’d require it
1
andre1sk
nope but had cases where I had other tables referencing it like “filter” it becomes a bit cumbersome, plus many ORMs don’t handle compound PKs (I dislike ORMs but it’s not always up to us).
1
OvermindDL1
I’ve often used actual SQL, I would here too except I wanted to give Ecto a try and I seem to quite like it, though I do have to fragment stuff up a lot due to Ecto limitations, so I’ve not seen that it was required by poorly made ORM’s (thankfully Ecto is comparatively not poorly made ^.^), I’ve tried to follow SQL tenents, even with my Ecto work (which is why almost none of my models have an ‘id’ field, well they often do, but not as Ecto would expect it to be so I have to @primacy_key false quite a whole lot).
3
StevenXL
peerreynders
As explained here (properly implemented) surrogate keys are motivated by the fact that changing domain requirements should never force a change on (the type of) a surrogate key. For example a unique customer number could be used as a natural key - but if the type of that natural key needs to change from numeric to alphanumeric, all the tables referencing that natural key need to be altered.
Ironically some current practices undermine the value of surrogate keys. One recommendation is:
Don’t naturalize surrogate keys. As soon as you display the value of a surrogate key to your end users, or worse yet allow them to work with the value (perhaps to search), you have effectively given the key business meaning. This in effect naturalizes the key and thereby negates some of the advantages of surrogate keys.
In particular the use of URI-templates like
/user/:uid/followings/:following_id
is acceptable if :uid is the identifier for the lifetime of the user but often :uid is actually the surrogate key for the record the user’s information is held in. By exposing it in this manner the surrogate key becomes part of the user’s information - i.e. for all intents and purposes it becomes a natural key (or at least the next data migration may have to treat it as such).
Maybe Joe Armstrong had a point with “URIs are bad” 
.
1
OvermindDL1
Heh, true, though :uid in my case can actually be a variety of values, the internal UID from LDAP, a C, a UserName, it all works like that at this moment. The :following_id would be similar as well, can lookup based on any unique value. Sadly the system I have to interact with has user facing ID’s (like the C and the UserName) and back-end unchanging ID’s (the UID), and the CNum and Username can change over time (though always unique), but the UID is constant, however no one knows that the UID even exists as it is never shown anywhere on the front-end of the main system I have to work with. >.>
1