Sgrubak ha scritto:
Non sono d'accordo. Un'anagrafica è un'anagrafica. Forse ragiono troppo OOP ma se dovessi scrivere una classe per gli alunni ed una per gli insegnato, la classica classe base Persone me la farei.
Applicando la logica alle tabelle, creerei l'anagrafica con i dati immutabili, e poi assocerei in tabelle apposite 1-M i dati relativi ad allievo e/o insegnante.
In questo modo ragioni sui dati e non sulla categoria. Qui abbiamo due categorie, alunni ed insegnati, e come per clienti, fornitori, amio avviso le anagrafiche ed i relativi movimenti devono viaggiare separati.
Suddividendo in categorie, anche modifiche successive, saranno piu agevoli, tipo aggiungere un campo ad una categoria non andrà ad influire sull intera struttura, ma solo su una parte.
Se si pone la necessità di modificare ad esempio qualcosa agli insegnati, ma che non interessa gli alunni, bisognerebbe modificare, oltre alle tabelle, anche le query preesistenti, in modo invasivo., i front end ed i report.
Per non parlare poi della possibilità di dover creare query kilometriche, che devono interrogare tutto il database, solo per trovare un valore atomico.
Inoltre non verrebbe intaccata nemmeno la normalizzazione del database, visto che non si sta parlando di dati ridondanti, ma di un altra categoria.
Che poi, per avere un database veramente normalizzato, alla fine bisognerebbe anche creare una tabella nomi ed una tabella cognomi, visto che, per assurdo, ci fossero 6 figli che frequentano la stessa scuola, ed il padre ex studente, ora fosse insegnate, ci troveremmo di fronte a 7 cognomi ripetuti. Se poi arriva un omonimo dei 7, siamo punto e a capo. Stesso discorso per gli indirizzi e le città. ( tra parentesi trovo utile una tabella città, indirizzo, perché questa è una categoria che veramente, verrebbe ripetuta per centinaia di utenti)
Comunque, a mio avviso naturalmente, se anche fosse intaccata la normalizzazione, in questo caso la quantità di dati ripetuti sarebbe comunque ininfluente sulle prestazioni del database, visto che tra migliaia di studenti, sicuramente pochi ritornerebbero ad insegnare in quella scuola. Quindi è uno dei casi dove si può violare la regola, in favore di un database più snello e performante.