Problema foreign key

[franzauker2.0]

I miei consigli
1) elimina del tutto le FK e gestiscile dall'applicazione
2) sempre nell'applicazione metti l' "intelligenza" per validare i dati prima di scriverli
3) vedo che non usi dati di default, ed hai un sacco di campi che possono essere NULL. Questo significa (prima parte) che dovrai avere logica nell'applicazione -e questo è bene- e che ne dovrai avere davvero parecchia per gestire i null -e pure questo è bene, ma devi considerarlo-

Meno ti appoggi su un certo RDBMS, più è facile in prospettiva sostituirlo, o anche solo aggiornalo, o perfino farci la manutenzione

Non lo mettere SER, non ha senso ed avrai solo problemi in backup-restore
`idALBERGO` INT NOT NULL AUTO_INCREMENT COMMENT

troppo corti: varchar più lunghi non ti costano nulla (in realtà sì, in fase di join con materializzazione della tabella, ma son quasi sicuro che le tue esigenze son così minuscole che non ti cambierà la vita)

`nome` VARCHAR(45) NULL COMMENT 'Il nome dell'albergo' ,
`viale` VARCHAR(45) NULL COMMENT 'Il viale in cui si trova ' ,

Non è un numero civico (intero), ad esempio 3/A, ti servono i char
`numero` INT(11) NULL COMMENT 'Il numero civico che gli appartiene' ,


"costo" non sono interi, se usano euro saranno DECIMAL

`costo_intero` INT(11) NULL COMMENT 'Costo del prezzo intero' ,
`costo_ridotto` INT(11) NULL COMMENT 'Costo del prezzo ridotto' ,

Neppure il telefono è un intero, perchè tipicamente ha lo zero davanti.
Inoltre può essere ben più lungo e contenere magari anche il +39

`telefono` INT(11) NULL COMMENT 'Recapito telefonico' ,

Indirizzi mail possono essere mooolto più lunghi
`mail` VARCHAR(45) NULL COMMENT 'Recapito e-mail' ,
`web` VARCHAR(45) NULL COMMENT 'Sito Web relativo all'ente' ,

Non ho proprio capito cosa sia idpaese, ma fa lo stesso
`idPAESE` INT NOT NULL COMMENT 'identificatore lago' ,

[bomberdini]

Un check per quello che vuoi fare te si puo fare nel seguente modo :

nella create table di albergo...

orario_f TIME check (orario_f < orario_i),

e poi prosegui con tutto il resto

[Jimmy5nomana]

@franzauker2.0 grazie, erano mesi che non ci tornavo sopra (sul db). E' un progetto da consegnare per un esame di basi di dati, quindi il problema della logica dell'applicazione non sussiste(schema e-r, progetto logico, sql); per questo le FK le devo per forza mettere qua altrimenti come collego le tabelle?

Non lo mettere SER, non ha senso ed avrai solo problemi in backup-restore`idALBERGO` INT NOT NULL AUTO_INCREMENT COMMENT

SER, cioè auto_increment dici? Tanto quando inserisco un item non incrementa comunque e ce lo devo inserire a mano, quindi credo lo toglierò (un'anomalia che non capisco)

Non ho proprio capito cosa sia idpaese, ma fa lo stesso `idPAESE` INT NOT NULL COMMENT 'identificatore lago'

Mi sono sbagliato a commentare, è "Identificativo del paese in cui si trova l'albergo"

Sul formato dei tipi dato in effetti hai ragione, thanks

@bomberdini

Si ma non trovo la sezione per inserire il CHECK in MySQL, è questo il problema. C'è TRIGGERS, ma una tab per i CHECK no. E leggendo su internet mi pare di aver capito di implementare il check come trigger

[franzauker2.0]

Originariamente inviato da Jimmy5nomana
@franzauker2.0 grazie, erano mesi che non ci tornavo sopra (sul db). E' un progetto da consegnare per un esame di basi di dati, quindi il problema della logica dell'applicazione non sussiste(schema e-r, progetto logico, sql); per questo le FK le devo per forza mettere qua altrimenti come collego le tabelle?

Lo hai "materializzato", con mysql
Ora se inserisco qualcosa nella tabella LAGO-rel-FIUME, le PK devono esistere nelle rispettive tabelle, altrimenti dovrebbe fermarsi o darmi un errore immagino; ma non avviene e fila tutto liscio
Stai appoggiando una parte della logica su "qualcosa" (l'RDBMS) che potrebbe, o potrebbe non, averla.
Non so come vi facciano fare gli esercizi

SER, cioè auto_increment dici? Tanto quando inserisco un item non incrementa comunque e ce lo devo inserire a mano, quindi credo lo toglierò (un'anomalia che non capisco)

come sopra

Si ma non trovo la sezione per inserire il CHECK in MySQL, è questo il problema. C'è TRIGGERS, ma una tab per i CHECK no. E leggendo su internet mi pare di aver capito di implementare il check come trigger

Certo che ci sono i check.
Peccato che mysql li ignori, semplicemente

Nuovamente starei molto attendo a vedere se è richiesto o meno implementare vincoli direttamente nel db, ottenendo qualcosa che è strettamente legato a mysql.

Se è un esercizio per quest'ultimo OK, ma per BD tipicamente non si danno (o meno non si davano ai miei tempi) problemi siffatti.

Riguardo a ID paese... ma che senso ha?

[Jimmy5nomana]

Riguardo a ID paese... ma che senso ha?

E' una AK (alternative key) nell'entità Paese per le PK: 1)Paese, 2)Provincia.
Paese è poi collegato ad entità come alberghi, monumenti ... e non voglio ripetere quei 2 campi (oltre al fatto che spreco spazio) per ogni record inserito in alberghi, monumenti ...

Allora ho inserito una AK nell'entità Paese e la uso come FK su alberghi, monumenti ...

Il database non è legato a una applicazione, quindi tutte le FK sono obbligatorie altrimenti non posso collegarle mi sembra. Sbaglio?
Ora.. scusa mySQL mi sembra sia un DBMS d'avanguardia.... per questo m isembra molto strano che io possa inserire FK nelle tabella relazione di 2 entità, come LAGO-rel-FIUME, e le FK non hanno riferimento a nessuna PK.

Non ho capito la parte sul SER

[franzauker2.0]

Originariamente inviato da Jimmy5nomana
E' una AK (alternative key) nell'entità Paese per le PK: 1)Paese, 2)Provincia.
Paese è poi collegato ad entità come alberghi, monumenti ... e non voglio ripetere quei 2 campi (oltre al fatto che spreco spazio) per ogni record inserito in alberghi, monumenti ...

Allora ho inserito una AK nell'entità Paese e la uso come FK su alberghi, monumenti ...

Non è una gran scelta, lo spreco di spazio è risibile, non c'è denormalizzazione e paghi invece un costosissimo join (anche più di uno).
Non so didatticamente come vi insegnano, dipende se viene dato un taglio realistico oppure sulla carta

Il database non è legato a una applicazione, quindi tutte le FK sono obbligatorie altrimenti non posso collegarle mi sembra. Sbaglio?

Sbagli

Ora.. scusa mySQL mi sembra sia un DBMS d'avanguardia.... per questo m isembra molto strano che io possa inserire FK nelle tabella relazione di 2 entità, come LAGO-rel-FIUME, e le FK non hanno riferimento a nessuna PK.

E' tutto tranne che all'avanguardia, anzi per anni addirittura non esistevano NEPPURE le FK.

Non ho capito la parte sul SER

I campi autoincrementanti hanno senso non tanto come succedanei delle chiavi primarie, ma per identificare in maniera univoca una riga per elaborazioni successive.
Un esempio "classico" è quello di un'applicazione che sta elaborando un certo record, poi si deve "spostare" da qualche altra parte, e poi tornare al punto precedente.
In questo caso si salva la chiave autoincrementante (il ser), si "smucina", poi ci si riposiziona sul ser iniziale

Nella fattispecie, per mysql, non è necessaria l'esistenza di una chiave primaria toutcourt (questo è previsto da SQL quindi è normale); nel caso dell'engine innodb se non ne esiste una essa viene creata "occultamente" (proprio come chiave autoincrementante) giacchè gli indici innodb vengono... indiciati sulla chiave primaria.

Come si sceglie quindi una chiave primaria? Tipicamente in modo che abbia senso.

Considera che in altri DB non esistono le chiavi autoincrementanti tout court, in altri sono dei pianti assurdi a dir poco (simulati con devastanti sequenze, come strofinarsi l'ortica sugli zebedei) etc.etc.

Va tenuto presente poi il dramma dei backup-restore, della fusione di eventuali copie (cose comuni in ambiti di produzione e non di carta)

[Jimmy5nomana]

Mmmh non capisco 2 cose:

paghi invece un costosissimo join (anche più di uno).

Per collegare Paese e Albergo (1:N) se non usassi la AK, dovrei fare comunque un join con le 2 PK di Paese; mi sfugge sicuramente qualcosa.. si.. all'università le cose hanno tutte un taglio abbastanza cartaceo.

Sbagli

E come si implementano altrimenti?

[franzauker2.0]

Originariamente inviato da Jimmy5nomana
Per collegare Paese e Albergo (1:N) se non usassi la AK, dovrei fare comunque un join con le 2 PK di Paese; mi sfugge sicuramente qualcosa..

Memorizzare una informazione atomica, o pressochè atomica, mediate una normalizzazione è un esempio di metodologia didattica.
Quindi va bene per insegnare "qualcosa" e quindi OK.
Nel "mondo reale" una informazione atomica (o quasi atomica), che vieppiù non varia nel tempo, la denormalizzeresti (anche se in questo caso bisogna prima stabilire formalmente cos'è una normalizzazione, perchè la cosa non è così scontata) tranquillamente.

Se ci pensi bene, portando alle estreme conseguenze, uno potrebbe avere una singola entità-tabella contenente SOLO la chiave primaria.
Poi tante entità-tabelle ognuna delle quali contenente la chiave primaria (importata ovviamente, quindi una FK) e un singolo attributo.

Sono tutte forme degeneri

si.. all'università le cose hanno tutte un taglio abbastanza cartaceo.

Dipende dal docente, mi rendo conto che per i corsi superbasici bisogna procedere con calma, prima si gattona, poi si cammina ed infine si corre.

E come si implementano altrimenti?

Non si implementano, ovviamente.
L'idea che le relazioni tra le entità siano qualcosa di "esistente", o "da materializzare" (mediante vincoli di integrità o quello che si vuole) è un altro esempio di deformazione didattica (lo dico in senso positivo, non dispregiativo).
Le relazioni... non esistono, così come chiavi primarie, secondiarie, 4, 8 e 16arie (questa è una citazione per chi non lo coglie), possono, o possono non, essere modellate dalla struttura del database.
E' l' "intelligenza" (oddio, per modo di dire) dell'applicazione a riflettere l' "intelligenza" infusa dal progettista e quindi delle sue idee delle relazioni


Versione breve, altrimenti vengo tacciato di essere un genio (!!)

Seguite tranquillamente gli insegnamenti dei corsi di base, però mantenete la consapevolezza che è un po' come la scuola guida: non è che imparate 4 manovre si è pronti per correre in F1.

Al massimo, se va bene, si fa un parcheggio senza rovinare il paraurti

[Jimmy5nomana]

Si ma dannazione a me non vanno i vincoli delle PK: il not null è come se non esistesse sulle PK, e se la PK è FK posso inserire qualsiasi valore anche se non corrisponde ai valori della PK nell'altra tabella. (cioè inserisco valori di FK che è PK della TABELLA-RELAZIONE che non hanno corrispondenza ai valori della PK della TABELLA-ENTITA riferita).

@franzauker2.0
posso chiederti se ci puoi guardare? Ti passerei il file, è leggero.

Ah sì mySQL fa schifo, crasha spesso; postgreSQL mi aveva dato un errore di installazione per questo avevo rimediato su mySQL ...

[franzauker2.0]

Originariamente inviato da Jimmy5nomana
Si ma dannazione a me non vanno i vincoli delle PK: il not null è come se non esistesse sulle PK, e se la PK è FK posso inserire qualsiasi valore anche se non corrisponde ai valori della PK nell'altra tabella. (cioè inserisco valori di FK che è PK della TABELLA-RELAZIONE che non hanno corrispondenza ai valori della PK della TABELLA-ENTITA riferita).

@franzauker2.0
posso chiederti se ci puoi guardare? Ti passerei il file, è leggero.

Ah sì mySQL fa schifo, crasha spesso; postgreSQL mi aveva dato un errore di installazione per questo avevo rimediato su mySQL ...

Bhè adesso che crashi spesso mi sembra abbastanza difficile, o meglio dipendente dalla tua situazione particolare, ho macchine che fanno più di 500 query al secondo 24h.

Puoi mandare, ti suggerisco di compendiare il più sinteticamente possibile qual'è il tuo problema (aumenta la probabilità che lo legga)