Několik bodů:
Zní to, jako byste právě používali to, co je na tabulce aktuálně jedinečné, a děláte to jako primární klíč. To funguje. A přirozené klíče mají některé výhody, pokud jde o dotazování kvůli lokalitě. (Data pro každého uživatele jsou uložena ve stejné oblasti). A protože tabulka je klastrovaná tímto klíčem, což eliminuje vyhledávání dat, pokud vyhledáváte podle sloupců v primárním.
-
Ale použití přirozeného primárního klíče, jak jste si vybrali, má také nevýhody pro výkon.
-
Použití velmi velkého primárního klíče způsobí, že všechny ostatní indexy budou v innodb velmi velké, protože primární klíč je zahrnut v každé hodnotě indexu.
-
Použití přirozeného primárního klíče není tak rychlé jako náhradního klíče pro INSERT, protože kromě toho, že je větší, nemůže pokaždé jen vložit na konec tabulky. Musí se vložit do sekce pro daného uživatele a příspěvek atd.
-
Také, pokud hledáte podle času, s největší pravděpodobností budete hledat celý stůl s přirozeným klíčem, pokud není čas vaším prvním sloupcem. náhradní klíče bývají místní pro čas a často mohou být vhodné pro některé dotazy.
-
Použití přirozeného klíče, jako je ten váš, jako primárního klíče může být také nepříjemné. Co když se chcete odkázat na konkrétní hlasování? Potřebujete několik polí. Také je trochu obtížné používat se spoustou ORM.
Zde je odpověď
Vytvořil bych váš vlastní náhradní klíč a použil bych ho jako primární klíč, spíše než se spoléhat na interní primární klíč innodb, protože jej budete moci použít pro aktualizace a vyhledávání.
ALTER TABLE tbl_rate
ADD id INT UNSIGNED NOT NULL AUTO_INCREMENT,
ADD PRIMARY KEY(id);
Ale pokud vytvoříte náhradní primární klíč, udělám z vašeho klíče UNIKÁTNÍ. Stejná cena, ale vynucuje si správnost.
ALTER TABLE tbl_rate
ADD UNIQUE ( user_id, post_id, type );