Attualmente trovo un lavoro e mi trovo di fronte a una tabella con circa 900 colonne nel loro database.
Non sono sicuro di cosa dovrei fare invece di riprogettare il database, per favore mi consigli di questa situazione che ho.
Le query per questa tabella sono davvero frustranti quando ho bisogno di alcuni dati in questa tabella e di unirmi ad altre tabelle.
(Questa tabella è stata progettata prima di me,)
Apprezzato,
Il modo migliore per affrontare qualsiasi problema software è capire, cosa è necessario ottenere e trovare una soluzione ragionevole e realizzabile per questo. Non è chiaro dalla tua domanda, qual è il tuo obiettivo.
Non vedo come l'unione con altre tabelle per una tabella con colonne 1k sia più frustrante per una tabella con 100 colonne o 10 colonne. È ancora un x JOIN y ON x.some_id=y.pk_id . L'unica possibile frustrazione è che se le persone non usano le chiavi sintetiche e si affidano a chiavi primarie naturali di più colonne, allora JOIN diventa un po 'lungo e un po' lento. Detto questo, ci sono tabelle per il data warehousing, che devono essere fatte in questo modo a fini di prestazioni. Altrimenti, introduci tasti sintetici auto-incrementati o unici al mondo e voilà. BTW, le chiavi uniche al mondo (alias UUID) sono necessarie solo se è richiesta la distribuzione e la fusione fuori banda. Per il magazzinaggio, scopri i fiocchi di neve e gli schemi a stella e magari ri-organizza i tuoi dati o semplicemente crea un lavoro di replica derivativa in un database separato.
Un tavolo con 900 colonne urla di un cattivo design? Più probabilmente. Puoi migliorare questo design? Probabilmente sì. È il tuo obiettivo immediato? Non sono sicuro, probabilmente no.
In un database abbastanza maturo che copre un dominio aziendale complesso, la frustrazione dei neofiti è inevitabile. I bravi architetti sono in grado di cogliere il momento in cui mantenere un database complesso è troppo debito, anche se è solo un debito di formazione di nuovi dipendenti, e iniziare a dividerlo in parti più gestibili con servizi separati su di esso. Forse anche microservizi. Ma non c'è il pranzo gratis. Dovresti superare un certo numero di ostacoli prima di raggiungere lo stesso livello di velocità e funzionalità dopo la divisione. Potrebbe persino causare sofferenze finanziarie alla tua azienda e perdere quote di mercato. Tutto questo semplicemente per un potenziale per crescere e scalare meglio. A volte i rischi superano i benefici e si finisce con uno schema di tabelle 1k con alcune di esse con colonne 1k. Benvenuto nel mondo reale. Nessuno paga per SELECT * FROM Customer e console.log("Hello, World!") .
Se desideri una risposta migliore, fai una domanda migliore. Una buona domanda dovrebbe sempre essere sulla falsariga di "Ho questa situazione, e devo trovarmi in questa situazione, ed è quello che ho cercato e provato, ed ecco la mia domanda: [domanda vera, niente scorciatoie, non chiedere consigli, non "cosa dovrei fare", una vera domanda deve essere qui] ". Buona fortuna!
Leggi altre domande sui tag mysql