Domanda

Ho notato che per Crystal Reports fatta dalla nostra organizzazione e da alcuni dei nostri fornitori di software ERA hanno la tendenza a utilizzare le tabelle fisiche per i set di dati i loro rapporti, invece di usare una vista o una stored procedure per raccogliere i dati . Di tanto in tanto i rapporti che ho visto utilizzare le stored proceedures che poi usare fisiche tavoli piuttosto che le tabelle temporanee per memorizzare e manipolare serie di dati. In questi casi l'output del rapporto spesso esiste come una tabella come rpt_ap_vendors o simili, e può o non può essere privo di dati quando non in uso.

Queste sono sempre casi in cui viene generato il rapporto a richiesta, quindi questo non è un caso in cui un rapporto potrebbe essere generato una volta e servito più volte, e non ci sono più relazioni / stored procedure di accesso a questi dati, allo stesso tempo .

Che motivo ci sarebbe per l'utilizzo di tabelle fisiche per i rapporti come questo? C'è una ragione logica, tecnica o le prestazioni relative a farlo? Nei rapporti che generano personalmente ho sempre usato viste e stored procedure con le tabelle temporanee o le tabelle derivate meglio ancora per evitare di disco aggiuntivo legge che coinvolge sgombrare / eliminazione di una tabella temporanea.

È stato utile?

Soluzione

(+) Motivi per creare una tabella fisica per memorizzare i dati del rapporto:

  • I dati del report è riutilizzabile. indico Crystal Reports o SharePoint al tavolo e quindi non preoccupatevi di come o quando spesso questi strumenti o miei utenti finali l'accesso ai dati. (Beh, in una certa misura, dal momento che più volte la lettura di un grande tavolo relazione cestinare la cache del buffer.) Posso anche mantenere una finestra scorrevole di vecchi rapporti per le inevitabili richieste lungo le linee di: "Può generare nuovo rapporto dello scorso anno ho? non riesce a trovare il CSV ho estratto in quel momento. "

    Questa è probabilmente la ragione principale è impostato in quel modo al vostro sito. Crystal Reports non può essere abbastanza intelligente per memorizzare nella cache i dati del rapporto in quanto gli utenti impaginare attraverso di essa o modificare le impostazioni del report. Quindi, nel caso peggiore CR sta rigenerando il vostro rapporto con ciascuna di queste azioni - un'operazione costosa e che richiede tempo. Con la tabella fisica semplicemente ri-interroga la tabella tutte le volte che è necessario.

  • Impostazione delle autorizzazioni sulla relazione è facile. Vuoi vedere questo rapporto? Bene, tutto ciò che serve è il permesso di leggere i risultati, non genera li . Quindi, ecco, hanno alcuni diritti di lettura su questo tavolo in uno schema bloccato e filegroup / spazio tabella.

Per la memorizzazione nella cache manualmente il report, è possibile controllare e isolare il processo di generazione di esso. Tu dai vostri lettori di report più libertà di agire e te stesso meno di cui preoccuparsi come DBA.

(-) quello che si perde con un tavolo rapporto fisico:

  • Flessibilità. Vuoi cambiare il rapporto? Argh, bisogno di alcune modifiche DDL.
  • spazio di archiviazione. Stai persistenti i dati sul disco, così duh.

Altri suggerimenti

In un precedente datore di lavoro, alcuni dei rapporti sarebbero volute ore per l'esecuzione. I rapporti di fine mese e di fine trimestre sono stati i peggiori (8 e 20 ore, rispettivamente). Calcolando i risultati, e la loro memorizzazione in una tabella permanente, l'utente può guardare i risultati del rapporto a piacimento senza ricalcolare i numeri al volo. Il processo che ha calcolato i rapporti è stato in grado di riavviare se era stato interrotto, in modo che anche aiutato: in quella parte del sud della Florida, ci sono stati più interruzioni di corrente secondo a lungo ogni giorno. Mentre l'azienda ha avuto un generatore on-site per i giorni di maltempo, non tutto il personale aveva UPS.

Alcuni dei "power user" ha voluto essere in grado di accedere ai dati e crunch i numeri in Excel, in modo che avevano accesso in sola lettura alle tabelle di reporting.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a dba.stackexchange
scroll top