Newsgroup: it.comp.software.database
Titolo: Colonne "multiattributo"

Ho avuto modo di vedere un db, il "classico" gestionale; prodotto
e modificato continuamente, risulta risentire dei tipici problemi
dovuti da modifiche a più riprese.
In particolare un errore mi ha colpito per il modo pervicace in cui
viene diabolicamente perseguito...
Nel campo "pagamento", implementato nel db come una
colonna singola (e qui sta il problema...), vengono riportate le
causali, es.:
1=riba
2=rimessa diretta
a cui successivamente si è pensato bene di aggiungere altre
modalità tipo contrassegno, carta credito etc implementate
come combinazioni tipo:
1=riba porto franco
2=rimessa diretta porto franco
3=riba franco destino
4=rimessa diretta franco destino
5=porto franco contro addebito immediato
6=porto franco contro addebito in fattura
a cui man mano si sono aggiunti alla bisogna un po' tutto quello
che serviva... assegni bancari, circolari, contanti, carte cred.,
30/60/90, rivalse ed esenzioni iva, e tutto lo scibile umano, finendo
per avere causali miste, generiche e/o multicomprensive, quand'anche
non contraddittorie... :-)))
La casella dell'inserimento è lunga un chilometro, e richiede
un'attenta lettura per non sbagliare, però "ha sbagliato l'utente
a inserire il dato, non il mio programma".
Naturalmente una tonnellata di IF si rende necessario per estrarre
significato da quel singolo valore.
Giustificazione del programmatore: "Così non devo fare validazioni
complesse; un valore è sempre 'giusto'" ...duh
Post-It sul monitor: "una colonna, un SOLO significato, grazie".

 3=riba franco destino
Non vedi che sono stati uniti più attributi in una sola colonna,
il che era il titolo del post? Ah, ma aspetta, vedo dal
subject che hai cambiato che forse intendevi altri "attributi".
In effetti talune pratiche portano ad un abbassamento della vista,
per cui sei scusato se non hai letto bene.

 
tse' ma questi sono dilettanti :)
la cosa piu' strana che mi e' capitata:
Domanda al "programmatore":
    su quale campo devo unire le tabelle X e Y (dopo ore di ricerche
bestemmie e c.)
Risposta:
   il campo a della tabella X e' collegato ai __primi quattro__ caratteri
del campo annotazioni della tabella Y
che idiota sono stato a non rendermene conto da solo, era palese ;)

 il che era il titolo del post?
Io sto lavorando ad un gestionale e nella colonna pagamento viene messo
l'ID di una tabella pagamenti in cui ci sono tutti i dati per calcolare le
scadenze ecc.

 
[CUT]
non male, non male, ma anche questa non scherza:
ACL di un servizio _a_pagamento_ implementata da classi di IP
o singoli IP separati da ";" tutti nello stesso campo varchar().
Sono ben accetti caratteri jolli es. la classe 192.168.* è valida
ecc. ecc.
La SP per parsare il campo è un esempio di triplo salto mortale carpiato
con doppio avvitamento senza rete!
:)

 Post-It sul monitor: "una colonna, un SOLO significato, grazie".
Questa è ancora più "distruttiva" anche perché pensata così
dall'inizio(non da me, ci tengo a precisarlo) e non a causata da
"successive modifiche":
Ho degli oggetti che sono identificati da id univoci (es. "10ABCD",
"10BCDE"), ogni oggetto è composto da n elementi identificati con un
numero progressivo.
Ho una tabella con un record per ogni elemento dove la chiave primaria
è __un unico campo__ varchar composto da id_oggetto-id_elemento (es
"10ABCD-1", "10ABCD-2", ecc...) (questo perché è meglio non avere
troppi campi nelle tabelle!!! ).
Quando bisogna cancellare tutti gli elementi di un oggetto viene fatta
una query "DELETE from elementi WHERE id LIKE '<id_oggetto>%';" !!!!
Tutto bene finché un giorno un ignaro utente inserisce un oggetto di
prova con id "10" .... (meno male che esistono i backup!)

 quanto nell'interfaccia utente.
Qualche calcolo:
metodo "tutto in uno": 1 colonna
possibili valori 2*3*4 = 24 - 3 combinazioni non permesse
= 21 possibili valori in colonna singola
Interfaccia utente: lista di 21 righe.
Per verificare se una spedizione è franco fabbrica: 10 o 11 IF
Schema normalizzato: 3 colonne, un valore in ciascuna
interfaccia utente: 3 controlli con un totale di 2+3+4
= 9 selezioni cliccabili + un vincolo lato db
Per verificare se una spedizione è franco fabbrica: 1 IF

 del campo annotazioni della tabella Y
LOL
Da qualche parte sul web c'è pure una tabella tipo (Chiave, CheTabella)
il cui secondo campo specifica su quale tabella sparare i join;
la stessa chiave, se di valore negativo, significava "universale".
La gente cerca sempre modi sofisticati di farsi male :-)

prova con id "10" .... (meno male che esistono i backup!)
LOOL, fantastica, meglio di una sql injection :-)))

The man with two watches ha scritto:

la telenovela continua:
solita domanda:
(tabella pagamenti vari e gia qui ...)
come faccio ad avere il riferimento all'origine del documento
risposta (sic):
il campo x e' formato da 6 caratteri il primo puo' essere
0, 1, 2, o 3 [speriamo ndOP] (sic)
   se e' 0 le cinque cifre successive si riferiscono al campo y della
tabella Y (sic)
  se e' 1 al campo z della tabella Z  (sic^2)
  se e' 2 ... (sic^2^2)
  se e' 3 ... (sic^2^2)
credevo ci fosse un limite ...