KBL ha scritto:
al momento tds non supporta un multilivello nella definizione del tipo (quindi o sono originali, o cover)
è ovvio quindi che Heidi o Jeeg, pur essendo cover come canzoni, come "pensiero d'amore di Mal" lo è di "message in a bottle" dei Bee Gees, devono essere inserite tra le sigle originali altrimenti le ricerche non funzionarebbero come ci si aspetta..
nel caso di un futuro passaggio al "multilivello" non credo sarebbe un problema aggiungere un'informazione in più
Non è tanto un problema di "livello" nell'ereditarietà di una cover.
Una cosa del genere è comunque da esplodere perché è un casino che a tutti gli effetti non ha senso implementare. Mi vengono i brividi a pensare ad un caso di cover multiple tipo "Tainted Love"...
Il problema sta da un'altra parte. Anche se so che potrei spiegare in termini tecnici e tu capiresti, cerco di essere più generico possibile perché il discorso potrebbe interessare anche altri.
I dati nel database, quelli che prima ho chiamato ENTITA', sono rappresentabili come tabelle. Pensate a dei fogli Excel: ogni riga è una entità, detta anche RECORD, e ogni colonna è una caratteristica (nome, anno, casa di produzione...) di un'entitò, detta anche CAMPO.
Per cui le canzoni hanno la loro tabella, i cartoni la loro tabella, e così via. Poi abbiamo le relazioni che legano una o più entità con altre, della stessa tabella o di altre, come "cover di" o "sigla di", come detto prima.
Io in OGNI MOMENTO posso sapere se una canzone è sigla di qualcosa (e volendo anche di cosa): basta seguire la relazione "sigla di" e vedere se trovo almeno un risultato. Analogamente posso agire per sapere se una canzone è o no una cover. Ed è quello che facciamo nei dettagli di una canzone, per riempire gli spazi "Altre versioni" e "Trasmissioni collegate".
Il problema sta nelle liste e nelle ricerche: se stessimo per OGNI canzone della tabella a seguire tutte le relazioni opportune per rispondere ad un utente che ha chiesto "fammi vedere solo le canzoni che sono sigle di qualcosa" avremmo un calcolo abbastanza pesante per il database.
Pensate, ad esempio, nell'analogia con i fogli Excel il fatto di dover saltare da un foglio all'altro per rispondere ad una domanda del genere, piuttosto che scorrere UN solo foglio.
Per cui alcuni dati, che sarebbero appunto calcolabili "a bisogna", sono stati "riassunti" in un campo apposito nella tabella. Tra cui ci sono l'indicazione "sigla/non sigla" e "cover/demo/ecc.".
Questo in gergo si chiama "ridondanza dei dati". Ha i suoi pro e i suoi contro. Da un lato risolve molti problemi. In primis, mi evita di andare a cercare in più tabelle, ma, cosa da non sottovalutare, mi permette di marchiare una canzone come "sigla" senza aver ancora inserito il rispettivo cartone (cosa che ci capita spesso). Dall'altro lato ci obbliga ad inserire e tenere aggiornati gli stessi dati in più tabelle.
Il problema sta in questo: attualmente il campo "tipo" nella tabella delle canzoni, e che viene usato nelle ricerche, può assumere un valore UNICO tra "cover", "strumentale", "base", "demo", ecc.
Il che vuol dire che è abbastanza limitato. Ad esempio non è possibile al momento indicare che una canzone possa essere sia BASE di una canzone che COVER di un'altra (pensiamo alla base di Jeeg Robot italiana...).
Ecco perché si è deciso di "scindere" la "catena delle cover" per nazionalità. Non è che non si potesse fare di meglio, ma non ne vale la pena per il momento.