You can certainly create a database such as you describe using Access, if that is what you want to do. I don't see any reason why it would not be feasible. If you want to include other relationships (tribe/clan/family), make those part of your logical data model at the start.
"Perfectly normalized" is a relative term. Normalize according to what you are trying to accomplish. 5th normal form probably isn't going to help in a reporting database where denormalized happens to be what is needed. What you need is a data model that matches what you plan to do with it. Define the entities and relationships in terms of the problems you need to solve. Normalize where needed, and denormalize where needed.
MS Access is OK, I guess, as a front-end GUI builder, if your expectations aren't too great. I've never worked with an Access application that was really well done. A few of them have looked impressive, but they were hard to use. I'm not saying that it is not possible to develop a good one, but I suspect that a lot of people give up before they arrive there.
Whenever I have tried to develop using Access I have run into an endless series of restrictions on what I could do. The SQL dialect itself has many limitations, and the VB programming environment is full of pitfalls. I haven't worked with it now for some years, and I don't know if it has moved on to VB.Net since then, but working with "On Error" in the versions I used was awful. If you are going to do everything in Access then you are probably going to be stuck doing GEDCOM imports and refreshes in VB.
On the other hand there are many things you can do with the forms features, if you know them well. If you don't, you may waste a lot of time trying to do things and failing because you didn't know the particular trick for that task. I say this as somebody that doesn't know all the tricks.
I would like to be able to import my data into a SQL database as well, in order to do queries against it that typical genealogy software does not do. I came across your question while looking to see what might already be out there.
I would be inclined to use SQL Server, because SQL Server development is what I do for a living. If you don't know it well, it can present a steep learning curve. But importing, refreshing, and exporting GEDCOM data is straightforward, if not especially easy, using Integration Services, standard reports can be created using Reporting Services (or even Report Builder), and I might even see possible applications for attribute management using Master Data Services. This is all on top of a powerful database engine, and all of these components are available in the Developer Edition for about the cost of a genealogy software package, if you don't count the time to develop the application, which could be quite a lot.
Personally, I don't have time to develop something like this right now, and I will keep on looking. Good luck.
What you have seems pretty solid. How about
create table vote (
user_id int not null,
content_id int not null,
time_recorded datetime not null,
vote int not null,
primary key (user_id, content_id),
foreign key (user_id) references `user`(user_id)
on delete cascade,
foreign key (content_id) references content(content_id)
on delete cascade,
check (vote = 1 or vote = -1)
);
A composite primary key with those two keys makes perfect sense. They absolutely should be foreign keys as well. I threw in to cascade a delete from the parent tables; if a user deletes, the "like" will be removed from the content (which, IIRC, is what happens in StackExchange), and if the content is removed, there is no real point in keeping the votes on it. I also implemented the vote column as an integer which must be either 1 or -1, rather than a boolean. That way you can get an overall tally of up and down votes with a simple sum(vote), rather than two select count(*).
Best Answer
Sounds like your looking for query notifications.
Exactly as you describe, this feature allows you to subscribe to notifications which are generated when the results of a query change. Typically more efficient than repeatedly polling the database for changes.
Under the hood, notifications rely on the mechanisms used to maintain indexed views. Because of this, notification queries are constrained by the same restrictions as apply to indexed views. It's a lengthy set of requirements that you should review in detail to determine if it would make this a non-starter for your scenario.