@dfox, i think it would be more comfortable to read notifications as "14 people upvoted your rant" instead of 14 "name upvoted your rant".
Of course, the notification count would remain 14.

I'd tried to do a efficient notification system like that. It's possible but it is f*cking complicated! I understand the feelings of @dfox.

@pneves What makes it complicated? I know a little of web-dev and DB management and it doesn't seems to be difficult, could you explain me?
Thanks

I actually "like" it the way it is, since we don't have a list of people who ++'d a given rant. So, right now you have no other way of knowing... But of course, if said list was to be implemented, it would be much nicer to see notifications the way you described

@altermind So, imagine that if you have a post with 100 comments from 100 different people, you will have 100 different notifications from each post. If you have a "like" (will call that just for context) on each comment, you will have more 100 different notifications on the database. If you have two likes for comment you will need to stack it when you generate the notification.
So now you can do:

FIRST CHANCE and like most people think:
Write an query algorithm that create all the notifications. This will be insane to develop and add more features in future, because if you want to show the first 10 notifications, one query will need to search for all the different types. Or have a query for every type, but search for 10 of each type (because if your last 10 notifications were from the same type, you will want to show them) and after that organize them and send them to the client.

Now imagine you have 100 likes on one comment and you want to show the notification like facebook "PERSON_A, PERSON_B, PERSON_C and 97 more, like your comment" you will search, just for that notification, for 100 connections, count them, select the last three, get the username of that persons, stack it and send it. This more another 9 notifications that could be this complex. Any DB system will crash right just you get a few more users.

SECOND CHANCE the best I get, but complex:
You create a specific database just for notifications. When something in database connects and need a notification, you create an ID for that notification on the connection and create the notification on the notifications database. Problem, data is not connected, so it will not delay and fill all the main database with lots of notifications (easily like I said before you get more notifications than normal data on the database).

If you want to stack notifications, related items will have the same notification ID and every time you change your name or want to stack something, you search for the notification and edit or add the new data and remove the unnecessary data. When you want to show the last 10 notifications, you just query the last 10 notifications and that's it. But a problem will surge when you have a complex operation like a name change and you will need to change on every notification that will show that.

For this you will need to have a background process that you call and in the meantime you give the response to the client, even if that background process is not finished. But the only problem but that everyone just give a sh*t is if someone call for their notifications on that moment and get the old name for a little time because the background process don't yet reached that notification. This requires a little more complex network with different machines. So probably won't worth it.

THE MOST SIMPLE NOTIFICATION SYSTEM:
When you create that like, you just point that something have a link (imagine a like) from someone and to return the notifications you create a query to search for items with notifications. From there you return them to the user and if someone deletes that link the notification will be deleted, because you are in fact returning the last 10 interaction with you.

THE SIMPLE BEST NOTIFICATION SYSTEM:
This is like a mix and the solution you will use for beginning one project. You have a different database for notifications but just hard code them. If someone likes your comment, you will create a notification with a param with the name of the person who likes the comment, a param with the type of the notification (a like) and a param with the url that it points.

Forget about name changing. The effort does not pay. At best, you will have a connection between the like and the notification and if someone delete the like, you deletes the notification.
This will open doors for you to escalate your system in the future.

To this, you can migrate the notifications database to another system so it won't generate too much work in the main database system and add the workers to edit the notifications to that machine or even another machine.
So this will be the best way to start a notification system, without too much work when you need to escalate your project.

Hope this helps you understand my point. Maybe sometimes my english were bad. Just ask and I will try to explain :)

And sorry for the spam xD

@altermind Forget to isolate the main problem, sorry!
Everything were is related to system and database query speed and performance. You can do a simple notification system with everything. But in a split of a second your database is full of notifications and slow as f*ck.

@pneves Oh shit, now I understand why its difficult... Thanks for the (super-complete) explanation

@altermind I imagine that you get scared with so much text ahah
good you understand :)

14 people upvoted your rant!
13 people upvoted your rant!
12 people upvoted your rant!
11 people upvoted your rant!
...