Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 12
  1. #1
    Utente di HTML.it
    Registrato dal
    May 2005
    Messaggi
    615

    [Postgre SQL] Tracciatura avanzata

    Carissimi, ho implementato un sistema che permette di tracciare ogni operazione che dovesse avvenire dalla mia applicazione. Ma... Se l'amministratore di rete entra nel db direttamente dal tool di amministrazione situato sul server e per qualche motivo modifica qualcosa? Esiste un sistema che permette di tenere traccia delle connessioni al db anche esterne alla mia applicazione, magari se non chiedo troppo senza scomodare i trigger che qualcuno di voi mi aveva sconsigliato?

    PS Nel mio attuale sistema di tracciatura uso una query non brevissima da scrivere. Vi chiedo, in generale, e potendo scegliere, è meglio inviare al db una query di selezione dalla mia applicazione, in modo tradizionale, o creare una vista interna al database da richiamare dall'applicazione con una normale select su tale vista? A istinto mi verrebbe da prediligere questa ultima versione, sia perché il linguaggio delle viste, l'sql, è del tutto db-indipendente; ma anche perché - correggetemi se dico una cavolata - in questo modo si alleggerisce lo scambio di informazioni applicazione - db visto che tutte le informazioni per eseguire la vista si troverebbero già nel db stesso. Ma allora mi viene da pensare perché non si usano SOLO viste memorizzate nel db eliminando ogni traccia delle query di selezione dalle applicazioni? Che ne dite?

    Grazie di tutto!

  2. #2
    Utente di HTML.it L'avatar di comas17
    Registrato dal
    Apr 2002
    Messaggi
    6,522
    Quello di scrivere tutta la query nel tuo applicativo è sicuramente la strada peggiore...

    Ti consiglio fortemente di utilizzare le viste, ed ancor di più, le stored procedures che risultano essere più modulari e potenti rispetto alle stesse viste
    Qui trovi una breve introduzione al tema, con una chiara spiegazione del perchè siano da preferire...(poi magari approfondiamo...)

    http://www.eioba.com/a70583/a_basic_...red_procedures

  3. #3
    Utente di HTML.it
    Registrato dal
    May 2005
    Messaggi
    615
    Comas grazie, che gentile.

    Ma sei sicuro che le viste siano DEL TUTTO indipendenti dal particolare db utilizzato, requisito che per me è di fondamentale importanza? Inoltre ti chiedo, ma a questo punto perché non eliminare dal mio applicativo OGNI TRACCIA di query di selezione, facendo lavorare solo le viste? E infine, mi confermi che così il carico di lavoro è inferiore perché le informazioni sulla selezione non devono essere trasmesse al db in quanto si trovano già nel suo interno?

    EDIT Ma sicuro sicuro che le stored procedure siano una buona cosa? Da quanto ne so dovrebbero essere piuttosto legate al particolare tipo di db utilizzato...

    Mi stai rassicurando su diversi aspetti, ti ringrazio

  4. #4
    Utente di HTML.it L'avatar di comas17
    Registrato dal
    Apr 2002
    Messaggi
    6,522
    Originariamente inviato da Shadow976
    Comas grazie, che gentile.

    Ma sei sicuro che le viste siano DEL TUTTO indipendenti dal particolare db utilizzato, requisito che per me è di fondamentale importanza? Inoltre ti chiedo, ma a questo punto perché non eliminare dal mio applicativo OGNI TRACCIA di query di selezione, facendo lavorare solo le viste? E infine, mi confermi che così il carico di lavoro è inferiore perché le informazioni sulla selezione non devono essere trasmesse al db in quanto si trovano già nel suo interno?

    Assolutamente no, le viste non sono altro che "normali" istruzioni SQL "già pronte"
    Ogni rdbms (SQL Server, MySQL, Oracle, PostgreSQL) utilizza un proprio "dialetto" che è certamente per molti versi rispettoso dello standard SQL ma altrettanto certamente ha alcuni suoi costrutti e forme "peculiari" (il discorso di creare un qualcosa che sia "assolutamente standard" per tutti i database è una cosa molto complessa, che potrebbe esulare dal presente thread, magari se ne può parlare in un altro...)

    Sicuramente (come anche indicato dal link che ti avevo messo) il fatto di utilizzare oggetti (viste, stored procedures) già residenti nel database ottimizza di molto le prestazioni ed è una pratica consigliatissima

    Ma ha anche degli altri vantaggi, secondo me non banali: immagina di dover eseguire una istruzione di select di alcuni campi di una tabella; se tu scrivi per esteso l'istruzione nel tuo applicativo, se ti capitasse di aver bisogno, per esempio, di richiamare anche un altro campo dovresti andare a modificare l'applicativo
    Se invece la medesima select la fai richiamando, ad esempio la stored procedure "pippo" (o la vista "pluto") ti basterà andare a modificare solo questa (nel database) perchè tanto il tuo applicativo avrà sempre e solo l'istruzione "esegui pippo"

  5. #5
    Utente di HTML.it
    Registrato dal
    May 2005
    Messaggi
    615
    Bene, visto che:

    1) Se può essere diversa la sintassi di creazione vista (problema non insormontabile, potrei creare diversi script di creazione db per ogni particolare motore che il cliente sceglierà) la sintassi per richiamare la vista dall'applicazione è invece del tutto identica, in quanto si riduce ad una select.
    2) I vantaggi non sono pochi

    Eliminerò dalla mia applicazione ogni traccia di query di selezione, limitandomi solo ad eseguire select sulle viste già immagazzinate nel db. Questa parte della discussione è termina, ti ringrazio.


    PERDONA LA MIA DIGRESSIONE, TORNIAMO ALL'ARGOMENTO DEL POST.

    (tra poco edito questo stesso messaggio, non rispondete ancora)

    EDIT: Ho studiato a fondo alcune risposte di diversi utenti in un mio precedente post, volevo inquadrare bene il problema prima di rispondere.

    1. Alla luce di quanto ho appreso userò le stored procedure infatti nessuno mi vieta di creare tanti script di creazione db quanti sono i diversi motori che il cliente potrebbe usare. Il problema della diversa sintassi risiede semplicemente nella creazione degli oggetti, non nel loro utilizzo da parte della mia applicazione scritta in Java, utilizzo che avviene sempre con la stessa sintassi (all'applicazione vera e propria non interessa il tipo di db scelto).
    2. A questo punto userò anche i triggers perché tanto la loro invasività o i problemi che potrebbero causare sarebbero estremamente limitati, stante il fatto che agirebbero per una e sola operazione, ovvero la scrittura del particolare evento verificato sulla famosa tabella di log.

    A questo punto, tra i vari linguaggi che mi offre PGSQL per creare function, quale mi consigli? Quale è accettato anche dalla maggior parte degli altri db (sql, c, PLPGSQL...)?

    L'uso dei triggers peraltro risolverebbe anche il presente quesito, in quanto un trigger si attiva comunque, a prescindere se il particolare evento coinvolto avviene dalla mia applicazione o direttamente da un utente loggato al tool di amministrazione del db situato sul server.

  6. #6
    Utente di HTML.it L'avatar di comas17
    Registrato dal
    Apr 2002
    Messaggi
    6,522
    Originariamente inviato da Shadow976
    A questo punto, tra i vari linguaggi che mi offre PGSQL per creare function, quale mi consigli? Quale è accettato anche dalla maggior parte degli altri db (sql, c, PLPGSQL...)?
    Io escluderei il C, che mi sembra qualcosa di molto peculiare di Postgre; come dicevo ogni rdbms ha un suo "dialetto" SQL; sono tutti simili e tutti diversi ....
    Io userei il "dialetto" SQL che ogni rdbms mette a disposizione (PLPGSQL, PL/SQL per Oracle, T-SQL per MS SQL Server, etc)

    Se lo scopo di avere un linguaggio "accettato" anche dagli altri è quello di non dover ogni volta reimparare e riscrivere da zero mi sembra vada bene

  7. #7
    Utente di HTML.it
    Registrato dal
    May 2005
    Messaggi
    615
    Sto studiano il sistema per procedere nel senso del consiglio che mi hai dato, farò modifiche non poco numerose! Prima che inizi, mi confermi che esistendo la grande possibilità offerta dalle viste, non esistono buone ragioni per non eliminare dalla propria applicazione ogni query di selezione, e per non gestirle invece interamente come viste? Se tanto mi da tanto, vale la pena farlo non per la query di tracciatura che avevo in mente, ma per TUTTE le query di selezione e interrogazione...

  8. #8
    Utente di HTML.it L'avatar di comas17
    Registrato dal
    Apr 2002
    Messaggi
    6,522
    Originariamente inviato da Shadow976
    Sto studiano il sistema per procedere nel senso del consiglio che mi hai dato, farò modifiche non poco numerose! Prima che inizi, mi confermi che esistendo la grande possibilità offerta dalle viste, non esistono buone ragioni per non eliminare dalla propria applicazione ogni query di selezione, e per non gestirle invece interamente come viste? Se tanto mi da tanto, vale la pena farlo non per la query di tracciatura che avevo in mente, ma per TUTTE le query di selezione e interrogazione...
    Puoi tranquillamente definire ed utilizzare una vista (o una stored procedure, torno a consigliarti fortemente l'utilizzo di stored procedures...) per ogni operazione di selezione che tu voglia effettuare...

  9. #9
    Utente di HTML.it
    Registrato dal
    May 2005
    Messaggi
    615
    Due quesiti.

    1. Ho sempre cercato di sviluppare secondo i criteri MVC, separando bene il model dal view e dal controller. In particolare, presumo che la parte di cui stiamo parlando rientri nel model (ossia la parte che tra l'altro racchiude tutte le query), o mi sbaglio? Ovvero, mettere tutto in viste (o, come mi consigli, lasciare perdere anche quelle per passare TUTTO, selezioni ed aggiornamenti, alle stored procedure) non significherebbe passare al db la parte del model e quindi non rispecchiare più quel criterio? Te lo chiedo anche perché a breve avrei avuto in previsione di studiare Hibernate, che mi dicono essere un ottimo ausilio proprio per quella parte. Quindi due sono i casi:
    1A. se dovessi lasciar fare tutto alle st. procedure Hinernate sarebbe del tutto inutile e la parte model passerebbe in toto al db
    1B. Le stored procedure vanno comunque richiamate, l'applicazione continuerebbe a rispettare i criteri MVC, solo che ora il lavoro sarebbe spartito tra applicazione e database. Diciamo un MVC più efficiente, e non avrebbe senso smettere di studiare Hibernate, visto che mi tornerebbe comunque utile.
    Quale dei due, 1A o 1B?

    2. Come da primo quesito, vorrei evitare che qualche amministratore di rete possa maldestramente modificare i dati dall'interno del db con evidenti conseguenze negative (tutti i sistemi di collegamento e storicizzazione gestiti dall'applicazione saltati, ecc). Se impostassi un bel trigger, anche eseguendo modifiche dall'interno del db ne resterebbe traccia nella famosa tabella di log. Ma se poi questa persona riuscisse ad accedere anche alla tabella di log, nascondendo magari la sua maldestra operazione eliminando la riga del relativo log... Non c'è proprio il modo di nascondere un oggetto, ovvero di non renderlo nemmeno accessibile all'amministratore del database ma solo alla mia applicazione?

  10. #10
    Utente di HTML.it L'avatar di comas17
    Registrato dal
    Apr 2002
    Messaggi
    6,522
    1) Premessa generale: ho l'impressione (bada bene, solo un'impressione personale, non vuole essere un giudizio nè tantomeno un'accusa) che tu stia dedicando molta (troppa ?) attenzione ad aspetti "teorici e formali" (la terza forma regolare, MVC, etc) che sono certamente importanti ed anzi, per molti versi "basilari" ma che rischiano forse a volte di farti perdere di vista aspetti implementativi secondo me altrettanto importanti: il famoso utilizzo degli ID univoci come chiavi primarie ed esterne, le iniziali idee sulle procedure per gestire la storicizzazione dei soci (che avrebbero portato a replicare inutilmente molte informazioni), etc
    Come ho detto più volte non conosco Java e quindi mi risulta ben difficile valutare quali possano essere i pro ed i contro di alcune scelte che coinvolgano specificamente Java ed i suoi aspetti (nei miei post ho sempre cercato di dare consigli "generici" applicabili a qualunque linguaggio e qualunque database); a maggior ragione mi risulta difficile valutare un pacchetto esterno, quale Hibernate, che, a quanto vedo dal suo sito, sembra essere molto potente e mirato anche all'utilizzo proprio con i database ("...query service...", "...its own portable SQL extension...")

    Nella mia esperienza (conosco bene MS SQL Server) ho sempre cercato di sfruttarne a fondo le funzionalità e le potenzialità, in particolare proprio l'utilizzo di funzioni, stored procedures, viste; tutti oggetti creati nel database e semplicemente richiamabili dall'applicativo in modo da riderre il carico elaborativo su quest'ultimo ed utizzare invece le funzionalità di ottmizzazione offerte dal motore del db stesso (e ridurre quando possibile la necessità di andare ad effettuare modifiche all'applicativo una volta rilasciato, magari per sistemare una piccola cosa...)
    Non conosco a fondo gli aspetti MVC per poter dire con certezza "chi faccia cosa" e se questo rispetti le suddivisioni formali indicate da questo o quel modello; io (consiglio personale) cercherei di sfruttare a fondo le potenzialità del database


    2) Temo che si rischi di entrare in un circolo vizioso senza uscita, e senza risposte certe. Un amministratore del database (non di rete, del database, ed ancor più un amministratore dell'intero database server) può per definizione fare quello che vuole nel database stesso, incluso quindi andare a cancellare i dati da qualche tabella e magari anche ripulire le tabelle di log.
    Temo ci si possa fare ben poco... Lo stesso amministratore potrebbe anche cancellare l'intero database o modificare password e permessi all'utente utilizzato per il collegamento dalla tua applicazione...
    Anche immaginando di togliere all'amministratore i permessi di cancellare la tabella di log, nessuno gli vieterebbe (se amministratore del server) di creare un nuovo utente, assegnargli tali permessi, ed effettuare operazioni "dolose" con le nuove credenziali...
    Non so come funzioni PostgreSQL, in SQL Server esiste anche il log delle transizioni (un file separato in cui resta traccia di tutte le operaziono, utilizzato per eventuali "ricostruzioni" del database), ma, anche in questo caso, un amministratore potrebbe comunque modificare alcune proprietà del database, effettuare alcune operazioni e far sparire anche queste informazioni.
    Ho l'impressione che non se ne esca: motivo in più per non dare a nessuno la password di amministratore e per non usare mai tale utente per collegarsi al database a meno che non sia assolutamente necessario, in modo da evitare anche il rischio di cancellazioni involontarie.
    Se vuoi provare a cercare maggiori dettagli o suggerimenti sul modo migliore di effettuare questa "gestione dei logo delle operazioni" ti posso banalmente suggerire (forse lo sapevi già) i termini con cui vengono generalmente indicate tali operazioni "audit trail"
    Google ti può dare una mano...

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.