<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-03-06 13:23 GMT+01:00 Daniele Varrazzo <span dir="ltr"><<a href="mailto:piro@develer.com" target="_blank">piro@develer.com</a>></span>:</div><div class="gmail_quote">

<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">E questo senza menzionare ORM non dico "scritti coi piedi" ma semplicemente non overingegnerizzati. Che magari non uso ora, ma in futuro chissà, e le basi di dati sono fatte per *sopravvivere* al codice: il tuo programma fra 5 anni magari non lo userà nessuno ma i dati che ha generato saranno un asset importante e altri programmi, che non sai con che tecnologia verranno scritti, li useranno.<br>

</div></blockquote><div><br></div><div>Vero!</div><div><br></div><div>Forse e' capitato anche a voi... trovarsi 1000+ tabelle senza alcuna foreign key, senza alcuna chiave naturale, senza constraint, con una media di 80-85 colonne per tabella.</div>

<div>Il tutto da migrare a una struttura NoSQL</div><div><br></div><div>Senza foreign key significa che neppure le colonne "ID" erano relazionate tra loro.</div><div><br></div><div>Ho dovuto scrivere un programma per cercare le relazioni sulla base dei contenuti. E molti test manuali.</div>

<div>Avrei dato il braccio destro perche', come minima regola igienica di base, ci fosse stato uno straccio di chiave naturale univoca.</div><div><br></div><div>Ma sono sicuro che l'ORM e il CRUD funzionavano alla perfezione in quel programma.</div>

<div>Perche' nei dati c'erano un sacco di schifezze, ma dall'interfaccia non si vedevano.</div><div><br></div></div></div></div>