Filippo Cerulo ha scritto: > Micron Engineering ha scritto: >> per questo esistono le query. Le tabelle non devono essere pensate in >> funzione dei dati da presentare in un report o in una maschera, devono >> essere un sistema efficiente di memorizazione, diciamo il livello più >> basso, il livello intermedio sono le query che forniscono i dati che >> servono per maschere e report. > Ah, ma a te sfugge sempre qualche piccolo particolare..... > > La possibilità di editare i dati di una Maschera basata su una Query > non è disponibile sempre. Dai adesso non diciamo stupidaggini... tutt'al più devi scrivere 2 righe di codice > > Dipende in effetti dal Front End utilizzato, ed inoltre non è quasi > mai possibile (a meno di giri di valzer...) su query uno a molti. Insisto è solo questione di codice... > Senza contare che l'aggiunta di un Record presuppone, nella tua > ipotesi, comunque un lavoro su più Tabelle, passando magari per > qualche sana istruzione Sql. Per definizione un record si riferisce solo ad una tabella; nella mia ipotesi per aggiungere un nuovo cliente devi aggiungere un nuovo record nella tabella clienti, un nuovo record nella tabella indirizzi e così via un record in tutte le tabelle in relazione con la tabella cliente (che abbia un senso per l'operazione che stai eseguendo dalla maschera). Considerando che l'inserimento di nuovi record in una tabella costa O(1) in n tabelle costa n * O(1) quindi le prestazioni sono comunque preservate. > Tutto per risparmiare campi? No, perchè strutturare i Db come si è > proposto in questa discussione non è certo un modello di semplicità.... Non risparmi dati, risparmi spazio disco e soprattutto sei più agile per modificare il db. Supponi che in seguito devi aggiungere ad es. un contatto skype che non avevi inizialmente previsto: devi modificare tutte le tabelle dov'è richiesto il dato. Nel mio caso devi solo aggiungere un tipo di contatto e quindi non devi nemmeno modificare la/e tabelle; se organizzi le maschere delle anagrafiche tipo master/dettagli (maschera + elenco dati o sottomaschera) per ogni tabella collegata dovrai solo aggiungere un controllo di testo o altro per il nuovo dato (se usi una griglia neppure quello). >> Purtroppo tu come molti altri vi concentrate troppo sulla presentazione >> dei dati e non sull'implementazione/gestione. Un pattern molto utile da >> seguire è MVC che razionalizza la struttura dell'applicazione. >> > Vabbè, se ti astenessi di fare ipotesi sul metodo di lavoro degli > altri senza conoscere i particolari, magari sarebbe meglio. Non era una critica (in ogni caso sarebbe costruttiva) ma un invito a pensare senza essere condizionati dalle "buone pratiche" presenti sui testi di basi di dati (ormai superati) e passare al pensiero object oriented che ha cominciato a farsi strada anche tra i db (vedi PostgreSql). > Qui stiamo facendo una discussione puramente teorica, comunque OT, su > un'ipotesi di partenza abbastanza banale. > Nei casi reali ho vistro strutture di Db di Gestionali anche famosi, > tenute insieme col super attack. Certo, modificare costa, progettare pensando alle modifiche future è un pò più lungimirante. > Ognuno ha il suo metodo, e io li rispetto tutti. Idem, se non volessi condividere la mia esperienza me ne starei zitto. > > Ciao. >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
