Di recente ho modificato manualmente alcune tabelle su un sito web Wordpress.
Ho anche avuto una certa esperienza con l'internazionalizzazione del database, quindi so che serializzare
non è la migliore opzione (IMO) per applicare più lingue.
Allora perché è fatto?
L'internazionalizzazione non era e non è l'unica considerazione data quando si decide come strutturare i dati all'interno del database.
Non posso parlare per WordPress (anche se sono relativamente certo che affrontano problemi simili), ma in Drupal, non è strettamente vero che tutti i dati sono serializzati: i moduli core e contribuiti possono accedere a uno standard SchemaSchema per descrivere i loro dati. Tuttavia, molti oggetti non sono banali e possono essere modificati a piacimento. La serializzazione dell'intero oggetto consente meno problemi durante la modifica della struttura degli oggetti.
Bret Taylor, CTO di Facebook, descrive in dettaglio questo problema riguardante FriendFeed per l'uso senza schema di MySQL. Ovviamente FriendFeed non funziona su Drupal o WordPress, ma è lo stesso problema.
Perché entrambi i sistemi sono stati avviati come progetti in una sola lingua e l'internazionalizzazione è stata aggiunta in seguito. E poiché i progetti erano già diffusi e il cambiamento nella struttura del DB avrebbe rotto la compatibilità con le versioni precedenti, sarebbe sembrato solo un'alternativa valida.
Ma questo è solo speculazioni su parte.
In realtà, la risposta (almeno per Drupal) non ha nulla a che fare con la retrocompatibilità. Drupal ha una politica di non mantenendo la retrocompatibilità tra le versioni principali. Piuttosto, andiamo avanti e rendiamo Drupal il meglio possibile con ogni versione della versione principale, e forniamo un percorso di migrazione in modo che il database possa essere convertito per la prossima versione durante il processo di aggiornamento.
Quello che descrivi è semplicemente ciò che accade quando lavori in un database SQL: devi decidere tra rallentare e complicare anche le query abbastanza semplici con una serie di join, o serializzare i dati in modo che gli elementi con campi diversi possano vivere nel stesso tavolo (che rallenta e complica un sacco di altre cose).
Ricorda, stiamo lavorando con tabelle qui: ogni riga deve avere le stesse colonne, proprio lungo la linea.