Schema Proposal Round 3

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.

3 Likes

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

2 Likes

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 :slight_smile:

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.

1 Like

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.

2 Likes

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.

2 Likes

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

2 Likes

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.

2 Likes

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.

4 Likes