In una tabella di lookup del tipo campotabellaA1id e campobtabellaBid, quando si ha una situazione del tipo 1-3, 2-3 deve usscire un output e quindi non consetirlo !
In pratica se ampobtabellaBid è tipo "date" devo evitare corrispondenza alla stessa data!
Proviamo a definire più chiaramente il problema.
Hai una tabella con [almeno] due campi: campotabellaA1id e campotabellaBid, chiamiamoli semplicemente A e B. Il loro tipo qual'è? Parli di "date", ma i valori che mostri non sono date.
Vorresti che, quando si cerca di inserire una riga nella tabella, se si verifica una certa condizione, l'inserimento non avvenga e sia mostrato un messaggio d'errore. È corretto?
Se sì, qual'è esattamente la condizione? Parli di corrispondenza di date, ma nel tuo esempio i valori 1-3 e 2-3 non sembrano essere in una qualche relazione evidente tra loro.
Quella che ho descritto è tabella di lookup Tipo numerico con chiave primaria
Ho 3 tabelle relazione molti a molti
Una tabella ha campo id di tipo numerico e campo di tipo date,
Altra tabella campo id e campo testo
L altra ancora è lookup table testoid, dateid
Quando data di due testi diversi é la stessa dovrebbe uscire output e quindi il testo deve essere riscritto per un altra data
A pensarci bene forse bastano due tabelle,
obiettivo cmq é avere un output di errore quando due testi inseriti fanno riferimento alla stessa data
Hai due possibilità:Citazione:
Quando data di due testi diversi é la stessa dovrebbe uscire output e quindi il testo deve essere riscritto per un altra data
- effettuare il controllo contestualmente all'inserimento, dunque evitando che nella base di dati possano masi esistere due testi con la stessa data
- effettuare il controllo a posteriori, quando nella base di dati ci sono potenzialmente già dei testi con la stessa data
Nel primo caso, con lo schema che hai attualmente, ti basta dichiarare le colonna dateid della tabella di lookup e la colonna con la data della tabella delle date come UNIQUE. In questo modo potrà esistere un'unico record per ogni data, ed un unico record di lookup per ogni data, di conseguenza un unico testo per data. Sarà la base di dati stessa a generare un errore se cerchi di inserire un testo associandolo ad una data già "occupata".
Nel secondo caso, un'interrogazione come questa (occhio ad eventuali errori di sintassi):
restituirà tutte e sole le date a cui sono associati almeno due testi.Codice:SELECT date.data, COUNT(*) FROM testo JOIN lookup ON testo.id = lookup.testoid JOIN date ON date.id = lookup.dateid GROUP BY date.data HAVING COUNT(*) > 1;
Probabilmente ne basta una sola, quella del testo, in cui la data diventa un attributo. Le interrogazioni diventeranno più semplici. A meno che non ci sia una buona motivazione per avere una data come entità a se stante.Citazione:
A pensarci bene forse bastano due tabelle
Ho pensato di cambiare la struttura ho aggiunto altre due tabelle
AFORISTA(ID, Nominativo)
Location(id, Numero_della_Location)
Ho a disposizione 10 spazi(location numerate) per Artisti/Poeti alias Aforisti, in determinate date
Ho pensato di creare due tabelle rispettivamente date, e location senza alcun legame (mi fa il prodotto cartesiano immagino)
dopo come posso aggiungere l'AFORISTA che occuperà la location in una determinata data?
La tabella per le location è comprensibile: anche se al momento ha un solo attributo (oltre alla chiave), è facile immaginare che sia possibile estenderla. Ma non capisco perché usare una tabella per le date, sarebbe molto più semplice (ed efficiente) un'apposita colonna nelle tabelle che ne hanno bisogno. Ti risparmi delle JOIN. A meno che queste "date" non rappresentino qualcosa di più di una data. Vedi tu...Citazione:
Ho pensato di creare due tabelle rispettivamente date, e location senza alcun legame (mi fa il prodotto cartesiano immagino)
È una relazione ternaria N:N:N, devi aggiungere una tabella per mettere in relazione quelle tre entità. Basta una tabella con tre colonne, non servono chiavi.Citazione:
dopo come posso aggiungere l'AFORISTA che occuperà la location in una determinata data?
Se rimuovi la tabella data diventa una relazione (binaria) con attributo, dunque basta una tabella con tre colonne: due chiavi esterne ed un attributo data.