Io ho l'impressione che tu abbia un Contratto, a questo contratto devi assegnare una serie di Articoli; ogni articolo ha un Codice e altri attributi.
In una situazione del genere, fai una tabella "contratti", e una tabella "articoli" dove metti tutti gli attributi (codice, etc, etc).
Poi, dato che ad un contratto puoi assegnare più articoli, allora fai una tabella "molti a molti" che disegna le relazioni fra la tabella "contratti" e la tabella "articoli".
Volendo, se il numero degli articoli è dinamico, si può anche complicare lo scenario, ma per ora direi che andrebbe bene così come descritto.
In questo modo puoi mettere gli articoli che vuoi, invece mettendo tutto sulla stessa tabella, hai un numero limitato di articoli, e una marea di altri problemi che si insinuano fra le righe di codice... belli pronti ad esplodere quando meno te lo aspetti, e quando magari hai già sviluppato il resto del mondo... quando andare a modificare ti costerebbe qualche anno di stipendi.
Rispondi quotando
quando andrai a lanciarla quella INSERT, metti caso che devi inserire tutti gli articoli disponibili, e metti che ogni articolo si chiama "supercalifragilistichespiralidoso", per tante volte, più tutti i codici... più gli altri attributi, io direi che stai facendo una query che va abbastanza OLTRE la lunghezza massima che un qualunque DBMS può sopportare.
più facile a farsi che a dirsi.
