Opracowałem system głosowania „lubię/nie lubię”.

Całkiem prosta tabela głosów, w której znajdują się id_artykułu, typ_głosowania (-1 lub +1)

Dwa unikaj takich SELECT SUM(vote_type) FROM vote WHERE vote_type = +1. Wpadłem na pomysł, aby przechowywać tę liczbę w mojej tabeli artykułów za pomocą systemu zdarzeń/odbiorników.

Co myślicie o tym?

0
JohnT 19 czerwiec 2011, 03:36

2 odpowiedzi

Najlepsza odpowiedź

Ten rodzaj działania (denormalizacja) jest bardzo standardową praktyką, gdy wydajność jest znacznie ważniejsza niż integralność danych. Więc IMHO jest więcej niż w porządku, aby zrobić to w twoim przypadku, ponieważ tak naprawdę nie obchodzi cię, czy liczba „polubień” dla strony z jakiegoś powodu nieco się nie zgadza.

Jednak i tak może być konieczne przechowywanie polubień w jednym rzędzie, jeśli chcesz również zapisywać informacje, takie jak kto co lubił, znaczniki czasu itp. Co w żaden sposób nie unieważnia tego, co powiedziałem w powyższym akapicie.

3
Jon 19 czerwiec 2011, 03:40
Cóż, być może źle wyjaśniłem, w rzeczywistości chodzi o to, aby zachować tabelę głosowania, ale tylko dlatego, że liczba głosów jest zbyt duża, chciałbym zachować przyrost liczby. Mogę uruchamiać crona każdej nocy, aby skorygować liczenie, jeśli z jakichś powodów nie jest to poprawne!
 – 
JohnT
19 czerwiec 2011, 03:50
@JohnT: Wtedy obowiązuje tylko pierwszy akapit. Kontynuuj zgodnie z planem. :)
 – 
Jon
19 czerwiec 2011, 03:55
Ok dziękuję! Czy byłoby wtedy źle mieć 4 kolumny wiadomości w mojej tabeli? (vote_up, vote_down, selection_up, selection_down) nie jest źle, gdy tabela staje się zbyt duża (mam na myśli kolumnę o numerze pov)
 – 
JohnT
19 czerwiec 2011, 04:08
@JohnT: Zależy od liczb. Jeśli masz 1 tys. artykułów i 1 mln głosów, nie zauważysz dodatkowych 16 KB dla 4 kolumn.
 – 
Jon
19 czerwiec 2011, 04:10

Bez względu na system, z którego będziesz korzystać, sprawa się nie zmieni.
Nadal musisz mieć taki stół jak teraz z article_id, vote_type (-1 or +1)

2
dynamic 19 czerwiec 2011, 03:39