Newsgroup: it.comp.appl.access
Titolo: [semi OT] Problema struttura e chiave primaria

Help........spiego meglio. Ho un applicativo già al lavoro che mi ha richiesto mooooooooooolti mesi per la messa a punto. Sembra che vada bene e che funzioni tutto.....ma salta fuori un problemino....
Si tratta di un gestionale per le librerie e tutto (ma proprio tutto, compresa la PK della tabella libri) si basa sul codice EAN del libro che ho scoperto oggi....non essere univoco! L'editore lo può riutilizzare a patto che il libro 'vecchio' sia messo fuori produzione. Quindi il dilemma......riscrivo tutto utilizzando una chiave surrogata che cmq ho (rabbrividisco al solo pensiero) o posso cercare di mettere una pezza in modo un attimino + indolore? Ho a disposizione anche un campo 'escluso', per determinare se il testo in questione sia in corso di validità oppure no: chiave multipla? Forse questa soluzione richiede meno manipolazioni ed aggiustamenti.......
Grazie a tutti x gli eventuali consigli......
-- 
Questo articolo e` stato inviato dal sito web 
http://www.nonsolonews.it

 Grazie a tutti x gli eventuali consigli......
A me pare che qualunque soluzione al problema sia "dolorosa". Se aggiungi un 
campo all'EAN per ottenere una chiave univoca multicampo, il gestionale 
dovr� cmq subire molte modifiche.
Anzitutto sulle chiavi esterne delle tabelle collegate, e poi sui recordsets 
scritti a codice che estraggono records dalle tabelle.
E' una situazione rognosa, eh?
Ciao: Oscar 

Oscar Manfredini ha scritto:

porcaccia si........
Al posto di dormire stanotte ho partorito questa......che mi sembra una follia......ma tant'�........
Se il libro � fuori corso, il suo EAN (l'entit� EAN PK) in verit� nn esiste +
Quindi sarebbe teoricamente errato continuare ad usarlo per identificare il record......bene. Se parto da qua, nel momento in cui si presentasse il caso di un nuovo EAN = ad un precedente, lancio una procedura che genera un nuovo EAN interno (univoco!!!!!!!) e va in tutti i movimenti (carico, scarico ecc ecc ecc) a cambiare l'EAN (cos� non perdo lo storico) e successivamente, una volta liberato il codice, lo assegna al nuovo libro....contro TUTTE le regole dei db relazionali.....Che dici? Follia pura? Vado a farmi qualche ora di sonno? Cambio lavoro? :-)
Intanto grazie....


 ha scritto nel messaggio 
news:gt3seh$gr8$1...@news.nonsolonews.it...


Mi pare che tu non abbia molte scelte.
1) Soluzione rapida ma non indolore. Chiave univoca costituita da pi� campi 
e manutenzione. Ma � la strada + radicale.
2) Soluzione meno indolore. Creati una tabella 1 a n dove il lato 1 � 
l'anagrafica libri e la tabella lato n contiene solo la chiave anagrafica 
libri pi� un sequenziale ed una data di fine validit� ed eventualmente altre 
informazioni. Dopodich� nelle procedure puoi interrogare la stessa tabella 
rendento sesibili le interrogazioni ad esempio confrontando la data del 
movimento con la data fine validit�. In questo modo crei una struttura 
scalabile ed non stravolgi la tabella di origine.
Ciao


Perch� follia?
Mi pare un'ottima idea per rimettere in carreggiata il DB senza impazzire.
Ciao: Oscar

Oscar Manfredini ha scritto:

Sicuramente � la strada + 'pigra' e dove rischio di meno di fare pataccate o dimenticarmi qcosa......c'� solo un punto il tutto il sw in cui posso cambiare l'EAN....quindi posso controllare la procedura e bloccare quello che serve senza troppi problemi.....mi sembra solo di 'contravvenire' pesantemente alle regole del db relazionale.....Grazie per le dritte......ci penser� su moooolto attentamente!!!!!


relazionale.....
Sicuro, ma ... "a mali estremi, estremi rimedi".
Resta da capire di chi sia la colpa di quell'errore (importante) in fase 
d'analisi: le chiavi primarie delle tabelle sono la prima cosa che non si 
dovrebbe 'fallare'  ;-)
Ciao: Oscar

Oscar Manfredini ha scritto:

Oh quanto hai ragione, oh quanto hai ragione...........
tutta mia......... :-(
grazie


 grazie
Fair hai considerato che Murphy si potrebbe accanire contro di te
e far utilizzare lo stesso EAN più volte?
-- 
-- 
MAssimiliano Amendola
www.accessgroup.it
Cisa - Conferenza Italiana Sviluppatori Access


Il punto focale � proprio questo.........e Murphy nn centra 'quasi' nulla........tutta 'sfarina' del mio sacco.........ma forse ho una sol.........ci penso e ve la posto.....



ho letto tutto e mi limito a dire solo 2 cose.
A2007 è un bel prodotto, ancora troppo buggoso, ma sta uscendo la sp2
http://blogs.technet.com/office_sustained_engineering/archive/2009/04/16/service-pack-2-for-the-2007-microsoft-office-system-due-to-ship-april-28th.aspx
Io lo uso da tempo ed ora mi ci muovo bene. Risolti i bug è davvero un prodotto da consigliare 
(io sono passato da 97 in poi e ho usato/uso tutte le versioni, ma preferisco quest'ultima)
-- 
-- 
MAssimiliano Amendola
www.accessgroup.it



Credo non siano del tuo parere developers abituati a features come :
"Protezione a livello utente", "replicazione dei DB", "accesso tramite 
ODBCDirect"
Oltretutto anche gli .ADP sono stati maltrattati...
Detto ci�, mi pare tu abbia sbagliato Thread  ;-)
Ciao: Oscar

Fair87 ha scritto:

Ho un'altra sol.......aggiungo una ulteriore cifra di controllo all'EAN (quindi 14 cifre) tipo 0 1 2 3 ......
Il campo � dichiarato a precisione doppia quindi nn ho problemi di spazio....con una routine ad hoc cerco il libro 'giusto' e nel caso faccio una form di passaggio per decidere quale (se ne trova + di uno). A video mostro sempre e comunque 13 cifre, cos� l'utente non sa manco che � cambiato qcosa.....Mi sembra ancora + semplice e privo di possibilit� di errore....


>>>>> mi sembra solo di 'contravvenire' pesantemente alle regole del db
Resto sempre dell'idea di una tabella a chiave composta 1 a n per i soli EAN 
eccedenti come soluzione meno dispendiosa ma non definitiva
Ciao 

 Ciao: Oscar
Ops... hai ragione,
sai sono un newbie ;-)



thanks a tutti.....provo le varie soluzioni....poi vediamo.....
