Originariamente inviato da franzauker
1) ABS è lenta, ti ho già spiegato come fare per vederla all'opera lentissima.
Per renderla meno lenta (ossia vediamo di rispondere alla domanda) devi ridurre al minimo, ma proprio al minimo, tutti i refresh dei campi calcolati.
Non conosco ABS, ma conosco il componente standard TDataSet di Delphi che, generalmente, elabora i "campi calcolati" quando è necessario, non una volta di più, non una volta di meno.

Tutt'al più, un suggerimento valido può essere quello di eliminare qualsiasi operazione "pesante" che possa essere eseguita all'interno dell'evento che Delphi generalmente richiama quando necessita di conoscere il valore di un campo calcolato (es. OnCalcFields); ad esempio, senz'altro non è consigliabile introdurre l'esecuzione di una query in un simile evento, poiché viene richiamato per ogni campo calcolato e per ogni record presente in tabella, ma in tutti gli altri casi (es. concatenamenti, calcolo di totali, ecc.) non vi sono problemi di alcun tipo ravvisabili in generale nell'uso dei campi calcolati.


Originariamente inviato da franzauker
Ridurre al minimo il refresh dei campi calcolati (il che significa "a manina", nel senso "quando li vuoi fare tu, e non quando li vuole fare qualcun altro")
I momenti e le modalità con cui i campi calcolati vengono elaborati non sono "casuali": anche se il codice è scritto da terzi, cioè da chi produce Delphi di fatto, ciò non vuol dire che la gestione dei campi calcolati sia priva di logica.


Originariamente inviato da franzauker
Anzi, meglio, puoi anche clonarti una tabella (o porzione) in una tabella RAM, operare su quella, e poi scriverla in un colpo solo con una transazione ABS.
Questo dipende da quanti record ci sono nella tabella. In ogni caso, questo è esattamente ciò che fa il componente TClientDataSet: memorizzare i record provenienti da un DataSet qualunque in memoria, gestire i cambiamenti e, infine, inviare al server (o all'origine dati) le modifiche apportate in un "colpo solo".


Originariamente inviato da franzauker
2) la "chiave" di qualcosa dovrebbe (dal punto di vista teorico) essere legato all'oggetto stesso descritto, e non ad un campo autoincrementante aggiunto posticciamente.
Cosa vuol dire "posticciamente": un campo che si autoincrementa non ha nulla di differente rispetto a qualsiasi altro campo della tabella, se non che possiede un compito ben specifico che è quello di identificare univocamente un record in modo sicuro anche in ambito multiutenza.

Una chiave legata all'oggetto descritto, come può essere il Codice Fiscale per un cliente di anagrafica, appartiene a un tipo più complesso rispetto a un campo intero autoincrementale, e ciò rallenta le ricerche, anche se basate sugli indici; inoltre, se ogni tabella correlata a quella del cliente usa come campo di correlazione una stringa da 16 caratteri o più campi al posto di un unico campo autoincrementale, ad esempio, lo spazio occupato dai dati aumenta oltremodo a dismisura.

Originariamente inviato da franzauker
Nel caso di specie il "problemino" riguarda a "cosa succede se il campo autoincrementante non rimane più quello che ti "aspetti".
Nel caso di specie, questo "problemino" non si verifica mai, perché il campo autoincrementale avanza sempre di una unità e, una volta attribuito a un record, per definizione non può essere modificato.


Originariamente inviato da franzauker
Ricorda che non hai il controllo sul suo valore.
E chi lo dice? Puoi ottenere il valore di quel campo come qualsiasi altro, così come puoi determinarlo con la totalità dei database SQL esistenti (MySQL, SQL Server, FireBird, ecc.), ed è proprio lo strumento che garantisce il corretto riferimento a uno specifico record di una tabella (dato che utilizzare altri campi per la chiave primaria può comportare che questa cambi se si modificano i campi sui quali essa si basa, rendendo impossibile gestire le "collisioni" se queste modifiche ai campi chiave vengono fatti da più utenti, cosa che non accade se si usa un campo autoincrementale).


Originariamente inviato da franzauker
Ciò può accadere (anzi in generale accade) con mysql ed i restore: il tuo programma, in sintesi, sarà difficilmente (se non impossibilmente) portabile verso altri motori db.
Ciò che rende portabile un database verso altri motori è lo standard SQL che si utilizza.


Originariamente inviato da franzauker
Ne deriva che, assai banalmente, conviene usare una chiave "vera" la quale può essere generata o da un gruppo di campi [...]
in questo modo, però, la chiave inizia a diventare lunghetta, facendoti perdere in prestazioni.
Appunto. E proprio per questo, non è una soluzione preferibile, rispetto a tante altre che invece risolvono questo e altri problemi.


Originariamente inviato da franzauker
A questo punto dipende da quanto vuoi "prendere in mano" la situazione, rispetto a "lasciarla così com'è".
Ma cosa vuol dire?


Originariamente inviato da franzauker
Nel primo caso, proprio ultrabrutalmente, ti basta usare un campo STRINGA. Nel secondo dipende se usi ABS o un database "serio".
Tutti i database sono "seri", anche perché non ne ho mai visto qualcuno "ridere".


Originariamente inviato da franzauker
Nel secondo caso puoi usare il CRC32 della chiave calcolata, mettendo un doppio controllo al momento del join
Fare il CRC delle chiavi di ogni record, sia quelli della tabella primaria che quelli della tabella secondaria da correlare, deve essere performante di brutto.

Poi, visto che sopra si parlava di "portabilità", sarebbe interessante vedere se è più portabile un campo autoincrementale (che esiste su ogni DB) rispetto a una funzione che calcola un CRC. La risposta, ovviamente, è implicita nell'ironia.


Originariamente inviato da franzauker
Questo per la gestione delle collisioni che, seppur rare, possono esserci.
Una chiave primaria univoca non deve mai dare luogo a collisioni, altrimenti la parola "univoca" cosa ci sta a fare?

In un sistema di gestione documentale, ad esempio, quando la "collisione" fortuita porta un cliente a visualizzare la fattura di un altro, sono problemi grossi...



Originariamente inviato da franzauker
fermo che è fondamentale tenere la "mente aperta" (niente visioni-tunnell) direi che è assai più interessante fare il contrario, ossia scrivi cosa vuoi fare, e come secondo te andrebbe fatto.
"Mente aperta" significa essere permeabili ai cambiamenti e alle metodologie che nascono per uno sviluppo corretto del software, non essere inclini a qualsiasi tipo di soluzione da "macellai dello sviluppo software", secondo me.


Originariamente inviato da franzauker
Questo per farti "intuire" che più ti "distacchi" dagli automatismi (che non sono altro che strati su strati) meno "automatismi" avrai ma, di conseguenza, maggiori prestazioni potrai ottenere.
Non bisogna però essere "fanatici", nel senso di reinventare la ruota.
Come tu possa affermare qualcosa e, subito dopo, il suo contrario, per me rimane sempre affascinante.

Ciao!