Non è affatto sciocco.
Considera le seguenti possibilità:
-
Archivia solo HTML. Quel è stupido! Una volta memorizzato in questo modo, modificarlo sarebbe doloroso: dovresti decodificarlo o semplicemente proibire qualsiasi edizione o forzare gli utenti a scrivere HTML.
-
Archivia solo testo. Potrebbe funzionare. Fino a quando, forse, scoprirai che convertire il testo in HTML è il collo di bottiglia¹ che rallenta l'applicazione. Per le app su piccola scala, questo approccio è ancora ok e probabilmente il più semplice.
-
Memorizza testo e HTML. Questo è ciò che hai scelto e presenta i vantaggi di entrambi gli approcci precedenti: la modifica dei contenuti è semplice e allo stesso tempo non rallentare l'applicazione verso il basso eseguendo la conversione ogni volta che viene generata la pagina.
Se c'è una cosa che è fastidiosa, è il fatto che stai usando due tabelle. Perché non conservare questi dati in un'unica tabella, con una colonna per il testo originale e un'altra colonna per HTML?
¹ Ricorda una regola: non indovina cosa rallenta l'applicazione: usa un profiler. Discutere quale approccio è più veloce è buono per un colloquio informale con i tuoi amici, ma non è un buon approccio per sviluppare un'applicazione scalabile senza fare lavori inutili. Ad esempio, il mio esempio di come salvare HTML rispetto a generarlo al volo è valido solo in teoria. In pratica, (1) memorizzerete comunque i risultati nella cache e (2) forse, chissà, il caricamento dei dati dal database potrebbe essere molto più lento della generazione di HTML.