La soluzione è quasi trovata.

1) Normale tabella con normale connessione e normale visibilità
2) Nessun uso dei trigger;
3) Per diminuire il carico di lavoro, tracciatura delle sole scritture e modifiche
4) Ovviamente tracciatura anche delle operazioni di login (anche se non a buon fine) e logout dal software
5) Nessuna tracciatura delle operazioni di lettura

Le operazioni di lettura oltre ad essere MOLTO più numerose e quindi a sovraccaricare in modo immane il sistema di log sono anche meno critiche ed importanti; non sono quelle che possono danneggiare il sistema (almeno non tipicamente) e riguardo le letture non autorizzate avrei comunque il log delle operazioni di login e logout (si badi bene, al mio programma e non al database!).

Ciò posto, se condividi, ti chiedo: ho un reale guadagno di prestazioni se memorizzo tale sistema di log in function residenti sul database, da richiamare tramite applicazione ad ogni scrittura / modifica, o a questo punto per semplificare ulteriormente posso limitarmi ad inviare al db una doppia query per ognuna di queste operazioni (ovvero, la classe che invia la query di scrittura dei dati ne invierebbe subito anche una seconda di scrittura sulla tabella log)?

PS (ho parlato in termini un pò volgari; è ovvio che nell'ottica della separazione da te indicata e che condivido in pieno non si invierebbe materialmente una seconda query ma si istanzierebbe una classe, separata dalle altre, che si occuperebbe SOLO della gestione di tale sistema di log. In tale classe, e solo in essa, risiederebbero ovviamente le query di scrittura del log)