This doesn’t change that the FK is a bigserial (though admittedly overkill for this particular table). Not sure how it is actually a problem.
OK, but then make sure that the display name can function as the real name field if the user so chooses. That means it must be able to accept upper/lower case letters and blanks. It must also be displayed everywhere with enough room to accommodate a reasonable name.
By the way, all these things are true about SE’s display name.
Yeah, that makes sense. There’s no need to place unreasonable restrictions on the display name anyway, so we may as well just accept whatever below a reasonable length (50, perhaps?)
50 should be enough. 30, the current limit on SE, is definitely not enough when people want to include both a real name or nickname together with a couple of words as a protest statement regarding events on the site. Which will hopefully never happen in Codidact
If it is just to give the vote a name, then IMHO it should be a name, say “up” and “down”. That is more clear than “+1” and “-1” in a context where you don’t really add/subtract anything based on the votes. Or even better, have a table for the vote names (so they can be localized if necessary), and use the id of the corresponding row instead of “+1”/"-1".
And as far as I remember, we explicitly decided to not have the difference up minus down.
Eh, maybe even 100, particularly if that’s bytes rather than characters (consider multi-byte encodings). But yes, the “display name” field should be long enough to accommodate a person’s full name, bearing in mind naming conventions from all over the world.
Actually, I think we agreed that we will likely have some combination of:
- Simple Difference Up/Down = Net Score
- A formula (can’t remember the source at the moment) that more reasonably reflects the “meaning” - i.e., 10 up, 1 down = 9 net (but overwhelmingly positive) is different from 100 up, 91 down (very controversial).
That is not what I remember. Rather from what I remember, we wanted to show upvotes and downvotes separately.
Indeed, I think showing the difference when we are not sorting according to it is a bad idea. The value shown would be completely disconnected from the ordering.
The formula for scoring was (upvotes + n)/(upvotes+downvotes+2*n) where n was a configurable parameter.
What we settled on, and recorded in the functional spec, is that we’ll display up and down counts, compute a score, and use that score for ordering. (Formula is in the spec.)
The post table has 4 columns for this
- Upvotes
- Downvotes
- Netvotes
- Score
Score is the computed column that is used for sorting. The point of the others is speed, its faster to read values than do counts from the post_vote table.
I don’t see the need of netvotes. Not only is there zero use for that value in our current specification, I also think that a simple subtraction will never be a performance issue should we ever need that value.