Newsgroup: it.comp.software.database
Titolo: Struttura db

Ho un problemino di concetto, dovrei importare dei dati da un db( tabella
unica), i dati che ricevo sono in alcuni casi duplicati ma vorrei importali
ugualmente, i db relazionali permettono di avere tabelle senza una PK ?, ci
sono alternative ?
i due db sono ancora da fare, quindi come dovrei procedere per costruirli in
modo da poter importare i dati anche duplicati ?
Ciao Mirko

 duplicati? Che senso ha?
Il senso non lo so, pero' e' tutto quello che ci ha detto il prof. per 
svolgere l' esercizio.
Tornando al mio problema, se metto una PK che non indica nulla 'una specie 
di GUID'
c'e' sempre la possibilita' che nell' altro db sia gia presente e quindi 
genero sempre un
errore di integrita'. Non riesco a ragionare sul problema !!
Ciao Mirko

 wrote in message
news:ejc20s$6go$
1...@aioe.server.aioe.org

???
Per quello che so io, se alla creazione della tabella non
dichiari un campo come chiave primaria (o non specifichi
un indice per chiavi formate da piu' campi) in una tabella
puoi inserire tutti i duplicati che vuoi.
... O c'e' qualcosa che mi sfugge?
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 puoi inserire tutti i duplicati che vuoi.
Dovremmo utilizzare Mysql non ne sono certo ma crede la ver. 4.1, quindi e' 
possibile in questo server sql
avere tabelle senza PK ?
A parte, e' comunque la soluzione ottimale oppure come dice Davide Bianchi 
si puo' inserire una chiave fittizia
anche se non capisco bene come fare. Mi servirebbe solo qualche idea.
Grazie per avermi risposto Mirko
 

 anche se non capisco bene come fare. Mi servirebbe solo qualche idea.
Hai provato a dare un'occhiata alla documentazione di CREATE TABLE?


 
In MySql puoi creare le tabelle senza chiavi.
In pratica pero' bisogna vedere fino a che punto possa essere funzionale.
Alla prossima.
	MAX

 ha scritto

se ho capito -- cosa di cui non sono affatto sicuro -- l'esercizio che ti 
hanno dato, partendo dalla tabella unica devi creare una tabella con le 
descrizioni non duplicate (select distinct), assegnando a ognuna una chiave, 
alla quale punterai dalla tabella dei dati che vai a creare con solo pk-fk.
desc
id - desc
1 - panno lenci
2 - pop corn
3 - pop rock
dati
id - iddesc
1 - 1
2 - 3
3 - 3
4 - 2
5 - 1
6 - 1
mi sfugge un po' il senso di una cosa del genere, a meno che le descrizioni 
non prendano 10 mega ognuna, nel qual caso, nell'esempio qui sopra, ne 
risparmi forse una 30ina. guadagni qualcosa anche in normalizzazione: 
correggi nelle desc e ti ritrovi la correzione in tutti i report dei dati.
ripeto: se ho capito. immagino che un senso l'abbia.
ciao, a.

 hanno dato
No la cosa e' piu' semplice, voglio poter travasare i record di una tabella
in un' altra tenendo conto che le due tabelle sono uguali, importando anche
i record uguali.
1. Se e' possibile in Mysql non uso PK.
2. Uso una PK e per essere sicuro di non trovare un corrispettivo sull 
'altra
    tabella genero via codice un GUID per la PK.
le performance ? , se interrogo il db con quale delle due posso ottenere 
risultati piu' veloci ?
3. Esiste un altro modo ?
Ciao Mirko
 

 i record uguali.
mi sfugge decisamente il senso della cosa.
cmq, select into?
ciao, a.

 cmq, select into?
Ma io parlavo della struttura che dovrei dare alle due tabelle, non del 
comando sql per importare i dati. Mirko
Es.
Tabella Cd Musicali
Titolo : Azzurro
Cantante: Celentano
Editore : EMI
Sull' altra tabella e' gia presente lo stesso record ma io lo voglio 
importare ugualmente per avere 2 record uguali visto che acquisendo i cd
mi ritrovo appunto 2 cd di Azzurro.Quindi la domanda e' come strutturo le 
due tabelle per poter importare anche i cd duplicati ?
Se non dovessi importare dall' altra tabella metterei una chiave surrettizia 
per ritrivarmi cosi:
PK                     Titolo             Editore
548FGT125       Azzurro          EMI
987OUHR9       Azzurro          EMI
2356YU45        Azzurro           EMI
Ma dovendo importare i record dalla prima in questo modo potrei ritrovarmi 
con 2 chiavi uguali, quindi che faccio non uso le PK ?
I Cd li tratto singolarmente per poter risalire in caso a chi li ho prestati 
per cui tutte le copie le voglio trattare come singoli pezzi.
Ciao Mirko 

 prestati per cui tutte le copie le voglio trattare come singoli pezzi.
ti sei mai chiesto come gestiscono accessioni e prestiti le biblioteche?
fai una tabella titoli distinct, con pk.
hai una tabella oggetti il cui campo iddesc e' una fk su titoli.
la movimentazione la applichi alla tabella oggetti, o con un campo 
prestato_a, o meglio con un idpersona fk su una tabella persone.
francamente come la stai impostando dall'inizio temo che girerai a vuoto a 
lungo. se butti tutto in una sola tabella, pezzi titoli e persone, non e' 
questione di pk/fx, stai facendo un foglio excel. puo' essere pratico, ma un 
db e' un altra cosa.
ciao, a. 

 
Se non erro, in qualche post piu' sopra hai scritto che e' un problema 
dato da un professore, giusto??
Se si, ti/vi ha espressamente detto che questa pratica e' assurda e 
completamente sbagliata??
	Se si, allora la cosa si risolve cosi':
		le prestazioni rimangono identiche perche' non hai una 				chiave 
funzionale, cioe' per cercare Azzurro non usi 				9870UHR9 (non la 
conosci, l'hai creata fittizzia), ma 				devi scorrere in sequenza tutti 
i record.
	Se no, forse e' meglio che si riveda un po' di teoria.
Se no, forse e' meglio che cambi mestiere
Alla prossima.
	MAX

 completamente sbagliata??
Quell' esempio l' ho fatto io, solo io, non ha a che fare con il compito :
Impostare 2 db su singola tabella con la possibilita' di importare i dati 
uno
nell' altro, tutto qui il resto l' ho messo io, cosa gestiscono i db e' 
irrilivante
lo devo decidere io.
Ciao Mirko 

 lo devo decidere io.
ho come il sospetto che parecchi qui pensino che ti devi chiarire un po' le 
idee.
che dati, e in che dimensioni, deve gestire un db _e'_ sempre rilevante. il 
db non entra nel merito delle descrizioni, che siano vinili magliette o 
ciliegie non conta. ma come questi oggetti si relazionano ad altri insiemi 
considerati dal db, conta, e parecchio.
cosi' come hai posto la questione, non ha molto senso.
ciao, a. 

 pezzi.
Anche in questo caso puoi comunque continuare a trattare i cd come
un insieme indistinto ("A Marco ho prestato X cd del cantante Y").
Prova ad approfondire tutti i concetti che girano attorno a
identificabilità, distinguibilità, unicità, primary key,
insiemi vs. liste, etc.; se poi vuoi buttare un po' di
benzina sul fuoco, puoi esclamare in aula "Siamo nel 2006, e
ancora non sappiamo del cat food argument!"(*).
Una sezione sulla storia dei database e degli errori del passato
dovrebbe imho essere sempre insegnata come obbligatoria agli studenti.
(*) Un grande classico ormai; era l'argomento che i sostenitori
delle tabelle senza pk (SQL-table) opponevano ai sostenitori
del modello relazionale (R-table). Sappiamo come andò a finire,
purtroppo...

 
Purtroppo sembra che le primary key surrogate siano l'unica soluzione
flessibile/possibile per poter creare software riusabile.
Sto studiando due prodotti, SQLAlchemy e Django, che propongono un ORM
per Python.
Benchè entrambi permettano di definire "a mano" le primary key, questo
porta dei problemi.
Ad esempio SQLAlchemy non permette la modifica delle primary key.
Saluti  Manlio Perillo

 Ad esempio SQLAlchemy non permette la modifica delle primary key.
Cosa intendi con "definire a mano le primary key"? Le pk sono
degli attributi come gli altri, con in più la capacità di identificare
e distinguere una riga da un'altra.
Il data modeler (come anche il programmatore) si deve limitare solo
a prenderne atto.
Cosa uso in programmazione, ossia come lo faccio manipolare dalla
macchina, *fintantoché non lo espongo all'utente*, è tutto un'altro
paio di maniche, ed è sostanzialmente una questione ortogonale al
data modeling.
bye

 
Saluti  Manlio Perillo