MySQL. Primary Key con valore NULL.

[caponemg]

Ciao a tutti,
Nel mio DB creato con MySQL ho una tabella di look-up (relazione molti-a-molti) fatta in questo modo :

Tabella -> Pneumatico
larghezza int not null,
altezza int not null,
diametro int not null,
carico int,
velocita int,
modello int not null,
prezzo int not null,
Primary Key(larghezza, altezza, diametro, carico, velocita, modello, prezzo);

Come vedete le colonne "carico" e "velocita" possono assumere valore 'NULL' e sono contemporaneamente settate come 'Primary Key' .

Può dare problemi questa tabella ?

[carlo2002]

Originariamente inviato da caponemg
Può dare problemi questa tabella ?

penso di no, non hai provato?

non sarebbe meglio usare come chiave primaria un numero id auto_increment?

[piero.mac]

Originariamente inviato da caponemg

Come vedete le colonne "carico" e "velocita" possono assumere valore 'NULL' e sono contemporaneamente settate come 'Primary Key' .

Può dare problemi questa tabella ?

una chiave primaria non puo' mai essere NULL (NULL significa che non esiste e non solo vuoto)

infatti mysql per prevenire boiate fa cosi':

A PRIMARY KEY is a unique index where all key columns must be defined as NOT NULL. If they are not explicitly declared as NOT NULL, MySQL declares them so implicitly (and silently). A table can have only one PRIMARY KEY. If you do not have a PRIMARY KEY and an application asks for the PRIMARY KEY in your tables, MySQL returns the first UNIQUE index that has no NULL columns as the PRIMARY KEY.

[caponemg]

Buongiorno a tutti.
In pratica vi spiego velocemente il progetto:
Consideriamo la scelta di un pneumatico per 'Auto, Moto' o per 'Quad' ,
i valori che descrivono gli pneumatici per Auto e Moto possono essere questi :
---larghezza , altezza , diametro, indice_carico, indice_velocita, nonchè marca del pneumatico, modello e prezzo---
esempio.: 205/45/R17 88 W Toyo - T1 R, € 100.00 .

Mentre gli pneumatici per Quad non posseggono nei loro valori 'indice_carico' e 'indice_velocita';
---larghezza , altezza , diametro, marca del pneumatico, modello e prezzo---
esempio per Quad :20/10/R7 Marca - Modello, € 50.00 .
Da qui l'esigenza di poter inserire nella tabella ->Pneumatico valori di 'indice_velocità' e 'indice_carico' uguali a NULL , ma a quanto pare non è fattibile!

Mi dite allora che l'unica soluzione, o la migliore, sia quella di creare due tabelle differenti una per
Tabella -> Pneumatico_Auto
larghezza int not null,
altezza int not null,
diametro int not null,
carico int not null,
velocita int not null,
modello int not null,
prezzo int not null,
Primary Key(larghezza, altezza, diametro, carico, velocita, modello, prezzo);

e una per
Tabella -> Pneumatico_Quad
larghezza int not null,
altezza int not null,
diametro int not null,
modello int not null,
prezzo int not null,
Primary Key(larghezza, altezza, diametro, modello, prezzo);

o c'è qualche altra soluzione più adeguata allo scopo.

Tipo

non sarebbe meglio usare come chiave primaria un numero id auto_increment?

che non mi è ben chiaro?

Grazie per ora,
Ciao.

[piero.mac]

credo non ti sia chiaro il concetto di chiave primaria.

In parole povere e comprensibili:

La chiave primaria serve per identificare in modo univoco uno specifico record della tabella, a prescindere dal contenuto del record stesso. I valori che inserisci nel record sono degli attributi di quello specifico record.

Quindi una chiave primaria ideale e': numerica, lunghezza fissa, senza relazione con il contenuto (attributi) del record, mai null, mai duplicata. Ecco perche' ti hanno suggerito di usare un campo numerico auto increment. Forse e' l'unico tipo campo che soddisfa (quasi) tutte le condizioni per essere la chiave primaria ideale.

A seguire poi ci sarebbe il discorso sull'ottimizzazione del database (le forme normali) ma se gia' sei in difficolta' con la chiave primaria e' meglio che leggi qualcosa in piu' sui database.

per esempio:

http://database.html.it/guide/leggi/87/guida-mysql/

[webus]

aggiungo che l'idea di impiegare in una chiave primaria valori variabili, come il prezzo, è l'anticamera di grossi disastri.

Consiglierei di usare una tabella separata pure per il listino prezzi.

[LeaderGL]

Fossi in te userei come chiave primaria al massimo "marca" e "modello".
Ma sopratutto mi farei una piccola cultura sui database prima di scrivere cose pericolose.

Se hai una tabella non ha alcun senso definire una chiave primaria con tutti i campi di quella tabella, sopratutto se questi (come ti hanno detto altri) sono variabili.

Quando ad esempio crei una tabella per la registrazione degli utenti che può avere come campi:
[list=1][*]Codicefiscale[*]Nome[*]Cognome[*]Nickname[*]Email[*]Password[*]Indirizzo[*]Citta[*]Provincia[*]Stato[*]...[/list=1]
se vuoi definirli tutti come una unica chiave primaria sei un pazzo...ti dovresti domandare:
Cosa rende (o deve rendere) unica ogni tupla (riga) di questa tabella?

Nel caso delle persone l'attributo che ci rende unici è sicuramente il "Codicefiscale" quindi probabilmente sarà lui il candidato migliore ad essere la tua chiave primaria; poi se per necessità ti interessa che non ci siano altri campi se ne può discutere.

Nel caso degli pneumatici sicuramente "Marca" e "Modello" dovrebbero indicarti con ottima approssimazione di quale pneumatico stai parlando.

[carlo2002]

io farei una cosa del genere...

Tabella pneumatico_auto:
  id_pneumatico int(10) unsigned NOT NULL auto_increment PRIMARY KEY,
  id_marca int(10) unsigned NOT NULL,
  id_tipo int(10) unsigned NOT NULL,
  larghezza int(10) unsigned NOT NULL,
  altezza int(10) unsigned NOT NULL,
  diametro int(10) unsigned NOT NULL,
  carico int(10) unsigned NOT NULL,
  velocita int(10) unsigned NOT NULL,
  modello varchar(255) NOT NULL,
  prezzo double(10,2) unsigned NOT NULL,

Tabella marche:
  id_marca int(10) unsigned NOT NULL auto_increment PRIMARY KEY,
  nome_marca varchar(255) NOT NULL,

Tabella tipi_pneumatico:
  id_tipo int(10) unsigned NOT NULL auto_increment PRIMARY KEY,
  tipo_pneumatico varchar(255) NOT NULL,

[caponemg]

Ciao a tutti.
Se avete un po di pazienza vi spiego perchè credo di avere bisogno di una tabella di look-up così formata.

Gli pneumatici (presupponiamo per le auto) hanno dei prezzi differenti non solo deducibili dalla 'Marca' e dal 'Modello' ma anche dalla dimensioni del pneumatico stesso;

per esmpio un pneumatico
' Toyo T1R ' 195/65/R15 91 H puo costare diciamo € 50.00
mentre il pneumatico con stessa 'Marca' e 'Modello' ma con dimensioni diverse tipo
' Toyo T1R ' 205/45/R17 89 W puo costare diciamo € 70.00.

Quindi il prezzo di un pneumatico è variabile al variare dei diversi dati inseriti nella tabella gia postata "Pneumatici_Auto" , tipo
---larghezza_1 , altezza_1 , diametro_1 , carico_1 , velocita_1 , modello_1 = Prezzo_1---
---larghezza_1 , altezza_2 , diametro_2 , carico_1 , velocita_2 , modello_1 = Prezzo_2---
---larghezza_2 , altezza_2 , diametro_1 , carico_2 , velocita_1 , modello_2 = Prezzo_3---

In pratica come vedete dallo schema tutti i valori hanno una relazione molti-a-molti fra di loro sicchè
---larghezza_1 può essere abbinata a diversi (ma non tutti) valori di altezza, di diametro, di velocità e così via;
lo stesso vale per gli altri valori
---altezza_1 può essere abbinata a diversi (ma non tutti) valori di larghezza, di diametro, di velocità e così via.

Logicamente per ogni valore inserito c'è una tabella collegata. C'è quindi la
'tabella_larghezza'
id ->1 , 2 , 3 , 4 , 5 .........
larghezza ->185 , 195 , 205 , 215 , 225 .........

'tabella_altezza'
id ->1 , 2 , 3 , 4 , 5 .............
altezza ->40 , 45 , 50 , 55 , 60 ..........
e così per le tabelle 'diametro', 'carico', 'velocità', 'modello', 'prezzo'.

E nella tabella (look-up) 'Pneumatici_Auto' ad ogni colonna corrisponde l''id' dell'omonima tabella:
( 'Pneumatici_Auto' . larghezza) == ( 'tabella_larghezza' . id).

In conclusione
" Il prezzo è dato dalle diverse combinazioni dei campi nella tabella 'Pneumatici_Auto'.
Ecco perchè la 'chiave primaria', nel mio caso, penso debba essere l'intera combinazione dei valori. "

Per quanto riguarda il rischio di inserimento dei valori NULL, in attesa di trovare altre soluzioni migliori, ho deciso di dividere in due tabelle (look-up) diverse gli pneumatici per auto e gli pneumatici per quad:

Valori che descrivono gli pneumatici per Auto e Moto possono essere questi :
---larghezza , altezza , diametro, indice_carico, indice_velocita, nonchè marca del pneumatico, modello e prezzo---

Tabella -> Pneumatico_Auto
larghezza int not null,
altezza int not null,
diametro int not null,
carico int not null,
velocita int not null,
modello int not null,
prezzo int not null,
Primary Key(larghezza, altezza, diametro, carico, velocita, modello, prezzo);

Mentre gli pneumatici per Quad non posseggono nei loro valori 'indice_carico' e 'indice_velocita';
---larghezza , altezza , diametro, marca del pneumatico, modello e prezzo---

Tabella -> Pneumatico_Quad
larghezza int not null,
altezza int not null,
diametro int not null,
modello int not null,
prezzo int not null,
Primary Key(larghezza, altezza, diametro, modello, prezzo);

Che ne pensate ragazzi, mi arresteranno !!?

[webus]

no, non ti arresteranno per questo, ma già il fatto che la tua impostazione ti porta ad adotare due tabelle diverse per tipolgie di pneumatici è indicativa del fatto che è sbagliata.

Riguardo al NULL:
la primary key che hai previsto (larghezza, altezza, diametro, carico, velocita, modello, prezzo),

10NULL200NULL120300
è diverso da
10NULL200NULL120300

perché due valori NULL sono diversi uno dall'altro (NULL <> NULL). Ecco perché non puoi avere valori NULL in una chiave primaria.

Usare un prezzo poi è addirittura una follia. Che fai il giorno che devi cambiare prezzo a un pneumatico?
Le chiavi primarie non si dovrebbero MAI modificare.

L'uso di chiavi primarie composte è buona cosa perché sono autoesplicative e hanno un senso compiuto, ma diventa rischioso usarle quando non hai ben presente i rischi a cui vai incontro. E diventano addirittura un ostacolo quando la loro lunghezza comporta un allungarsi dei tempi di ricerca nell'indice.