Delphi 2010 Datasnap - Query di progettazione

Question

Sto studiando lo spostamento di un'applicazione client Delphi basata su SQL di spessore su thin client Multi Tier e ho cercato di utilizzare Datasnap in Delphi 2010. Ho lavorato attraverso il White Paper scritto da Bob Swart e esteso questo ulteriormente.

La mia domanda principale è che voglio rendere il lato server efficiente in termini di connessioni e query SQL a causa di più query eseguite e restando aperte allo stesso tempo per interrogare i dati, chiunque può indicarmi una direzione per guida su come progettare un'applicazione Datasnap Server del mondo reale, in quanto le demo non sono sufficientemente dettagliate.

Grazie Matt

Answer 1

Dovete decidere nel vostro progetto:

• (Mid-Server) gestirà sessione o cliente identificherà la loro sessione di ogni connessione (stateful vs stateless)

• (Mid-Server) Quanti dati memorizzati nella cache desiderate. Puoi mettere in cache solo alcune fastidiose tabelle molto stabili e interrogarle solo quando cambiano (se tutte le modifiche sono attraverso il mid-server, in caso contrario, hai bisogno di qualcosa come un segno arbitrario - un GUID, un contatore - sul tavolo per corrispondere se i dati cambiato).

• (Client/Mid-Server) Se il cliente ottiene sempre una raccolta completa di dati o solo frammenti della raccolta. (es .: un prodotto può avere una colonna categoryId, che è un FK di una tabella di categoria.È possibile inviare sia tutto il tempo che il cliente può richiedere solo i dati del prodotto).

• (Mid-Server/RDBMS) Potrebbe essere necessario fornire una forma di ricerca personalizzata. Se hai un indizio delle condizioni di ricerca più utilizzate, puoi fornire (se necessario) la copertura dell'indice per farlo.

• (Mid-Server/RDBMS) Non portare grandi insiemi di dati a metà server, a meno che non si preveda di eseguire una memorizzazione nella cache aggressiva dei dati e/o di utilizzarli correttamente. Mid-Server è solo un'altra applicazione client per RDBMS - se entrambi si trovano sulla stessa macchina, è possibile entrare in una competizione di memoria/CPU/IO con RDBMS.

• (Mid-Server/RDBMS) Esegui le tue regole aziendali sul Mid-Server, è il mantra di molti puristi là fuori. Per me, l'equilibrio è la chiave. Diciamo che l'RDBMS ha 2000 Stored Procedure (non sto esagerando, c'è un vero business con un tale numero di SP) e il tuo Mid-Server può fare un ottimo lavoro su 1500 di quei 2000 problemi risolti da SP, GREAT e farlo. Ma se gli ultimi 500 possono essere un cambiamento nel peggiore dei casi, lasciali soli. Può essere una seccatura maggiore rispetto al 1500 .. Quindi mescolare i due e rendere quei 500 un progetto software ad un'altra versione.

• (Mid-Server/RDBMS) Quello che ho detto per Stored Procedure può anche essere applicato a trigger e altri tipi di funzionalità del server RDBMS che possono rendere più facile la vostra vita.

• (Mid-Server/DataSnap) La maggior parte dei dettagli grezzi può essere lasciata al provider di set di dati. Ma impara a sfruttare l'evento OnBeforeUpdateRecord per eseguire l'elaborazione personalizzata quando necessario.

• (Mid-Server/DataSnap) Sapete che è possibile creare un ClientDataset solo con i dati modificati tramite sotto questo tipo di codice? Non puoi immaginare quanto possa essere utile ... :-)

  Cds_New.Data: = Cds_Updated.Delta;