Quali considerazioni speciali sono necessarie quando si progettano database per conservare i record finanziari?

Riceverai molte risposte a questo sono certo, anche molte risposte idealiste, posso solo rispondere dalla mia esperienza con i finanziari e ciò che accade in realtà.

Hai già coperto la maggior parte dei problemi.

La precisione dell'arrotondamento tende a non essere in effetti un problema nella mia esperienza. La maggior parte delle grandi organizzazioni finanziarie che non sono cresciute da un giorno all'altro (vale a dire tutto tranne gli hedge fund) hanno una vasta gamma di applicazioni legacy che sono suddivise a causa di vari combustibili. Tendono a non arrotondare costantemente la precisione; generalmente un certo errore di profitti e perdite è semplicemente accettato per arrotondare. In effetti, molte ore di lavoro sono spesi in luoghi in cui ho lavorato dove gli umani sono i selezionatori finali "sì che sono abbastanza vicini" quando si tratta di confrontare somme esatte / previste. Ricorda, questa è una risposta basata sulla realtà, non su cosa dovrebbe accadere.

Crittografia: non fare affidamento su di esso francamente. Memorizza i dati identificativi in un sistema separato fisicamente e logicamente rispetto ai dati non identificati (ad esempio, codice account ovunque, dati personali separati).

Generalmente, mentre i backup sono richiesti, i backup offline sono raramente richiamati - le cose sono andate male in quel momento. Generalmente sono richieste copie di produzione calde, tuttavia ciò dipenderà dalle vostre esigenze specifiche. Nella pratica generale disponiamo di una copia di produzione in loco di tutti i sistemi E di un sito di disaster recovery con produzione propria e copie calde. Le copie calde tendono ad essere pochi minuti indietro nella replica ecc.

L'auditing è la chiave di ogni sistema finanziario su cui abbia mai lavorato. Hai 2 requisiti fondamentali A) Riesci a tenere traccia di ogni singola modifica apportata ai dati, da chi, quando e perché? B) Puoi provare lo stato storico dei tuoi dati? Che non è stato manomesso?

A) è richiesto per i team operativi: il tuo sistema verrà utilizzato in 100 modi che non ti aspetti, e questa informazione è vitale per l'espansione, i report ad-hoc, i motivi legali e il debug.

B) Vedi il caso AMEX vs. Vee Vinhnee - dove AMEX non era in grado di incassare 40.000 dovuti a loro poiché non potevano dimostrare che i loro record non erano stati inventati. La soluzione generalmente utilizzata per questo è il timestamp attendibile. I grandi finanziari hanno banche garanti che garantiscono le transazioni e quindi forniscono intrinsecamente il timestamp di fiducia. Ci sono fornitori commerciali per questo per altri percorsi di vita / scenari.

Le considerazioni sono per lo più legali . Se guardi da un punto di vista della sicurezza / affidabilità, un foglio Excel potrebbe non essere intrinsecamente meno sicuro di un foglio di carta in un cassetto. L'integrità transazionale dell'accesso potrebbe essere migliore di quella di un impiegato che viene interrotto da una chiamata.

Tuttavia, affinché i tuoi clienti possano utilizzarlo, devi conformarti alle leggi locali. Alcune cose che ho incontrato (in Germania)

• Formati di documenti per materiali di archiviazione , perché esistono leggi che le aziende devono conservare i loro documenti per 10 anni. Tra 10 anni, forse il tuo programma non è più disponibile. Pertanto, è necessario archiviare i documenti in un modo certificato DIN / ISO (il formato PDF sembra sufficiente in Germania)
• Percorsi di controllo sono spesso necessari, ad es. potresti dover presentare versioni diverse dello stesso documento, con date di modifica.
• La posizione dello spazio di archiviazione , a causa del "Datenschutz" (privacy), che potrebbe essere diverso nel paese di archiviazione. Ciò rende i servizi basati su cloud un po 'complicati.
• Alcuni documenti devono essere archiviati in modo non modificabile . come esattamente questo risultato sembra dipendere in gran parte dal narcotismo legalistico (un documento è immutabile, un cd è mutevole, un cd firmato da un lavoratore non lo è)

Dovresti contattare in modo definitivo un avvocato, per specifiche o almeno lavorare in stretta collaborazione con un cliente.

I fattori di affidabilità diventano sorprendentemente importanti quando hai a che fare con i soldi delle persone. Se Twitter perde un tweet, non è un grosso problema; se addebiti la carta di credito di qualcuno ma perdi l'ordine, qualcuno nella tua organizzazione riceverà una stima da un cliente arrabbiato. Quindi due cose: 1. Non vuoi che ciò accada in primo luogo, ma 2. succederà alla fine non importa quanto sei attento, quindi vuoi mettere MOLTA energia nel tipo di meccanismi di registrazione e tracciamento ciò ti aiuterà a tornare indietro ea trovare l'ordine "perso" e correggere la situazione.

La cosa peggiore in assoluto è avere, ad esempio, un addebito su carta di credito, ma NESSUN record per quello a cui è destinato, o a chi appartiene, ecc.

Per questioni finanziarie, devi davvero pensare anche agli scenari apparentemente super improbabili e pianificare come gestirli: "Abbiamo addebitato la carta di credito, ma il server del database è inattivo prima di poter aggiornare il record corrispondente. " OK, e adesso? Annullare la carica? Registrare la transazione in un file in modo che un essere umano possa risolverlo in un secondo momento? Ok, e se il disco è pieno e non puoi scrivere sul file? Ecc., Ecc.

[1] Utilizza le tabelle di sicurezza (non confonderlo con gli utenti interni D.B.) per gli utenti e per la tua app. moduli, moduli, pagine web:

User = {userID, username, pwd, email1, email2}
Modules = {moduleID, moduleTitle, moduledescription}
ModulesPerUser = {modulesperuser, userID, moduleID}

[2] Non eliminare i record nella tua app., usa un campo di stato, forse intero, forse booleano o bit, che indica che il record è considerato "cancellato". Fai la tua app. mostra i record che non vengono cancellati (contrassegnati come cancellati, da quel campo) e crea alcuni moduli caso speciali, dove l'app. mostra i record contrassegnati come cancellati.

anytable = {anytableID, anytablefield1, anytablefield2, ..., bool anytableisdeleted }

Questa funzione è chiamata "cancellazione virtuale". La vera eliminazione viene chiamata in modo casuale "cancellazione fisica".

[3] Usa i campi in tutte le tabelle che riguardano l'accesso, memorizza l'utente (singolo) che crea il record e l'utente (ultimo) che ha modificato il record e il datetime, se possibile aggiungi il modulo o l'opzione dove ogni record è stato modificato:

AnyTable = {anytableID, anytablecreateuserID, anytablecreatedatetime,
anytableupdateuserID, anytableupdatedatetime,
moduleID, anytablefield1, anytablefield2, ..., anytableisdeleted }

[4] In alcuni casi, i valori di valuta o denaro possono influire sui risultati, quando vengono utilizzati più record in un dettaglio e, aggiunti in un singolo valore, in un record di intestazione.

La maggior parte delle marche di database supporta, oggigiorno, un campo di dati monetari o monetari. Usalo.

In alcune circostanze speciali, alcune persone le memorizzano in un valore float fisso che supporta diverse cifre decimali, ("decimale") o addirittura come valori stringa.

Questa tecnica è un'arma a doppio taglio. Se la tua applicazione richiede quel tipo di presentazione, cerca nel web, per un tutorial su come implementarlo, correttamente.

Saluti. [non dimenticarti di dare un barattolo di tonno aperto al gattino, o un uplle nonleast]

Hai taggato la tua domanda con security ma parli principalmente di coerenza e affidabilità, quindi proverò a rispondere a questa parte dell'equazione:

• Utilizzare le transazioni del database per garantire l'integrità delle operazioni batch. L'esempio più semplice è un trasferimento tra due account: un account viene detratto dall'importo e l'altro viene accreditato. Utilizza le transazioni per garantire che un trasferimento parziale non avvenga mai (viene modificata solo una parte).
• Per precisione, usa il tipo DECIMAL invece di float. I calcoli sono molto più lenti ma non dovresti sentirlo poiché la maggior parte dei calcoli finanziari sono molto basilari
• Utilizzare la replica per uptime e hotcopies per il backup. Dovresti anche cercare snapshot LVM per il ripristino

Alcune delle considerazioni che vedo sono che devi tenere conto dei controlli interni. Ciò significa che tutti gli accessi per le azioni rispetto alle tabelle (Insert / delete / update) devono avvenire tramite stored procs (e nessun SQl dinamico) in modo che nessuna tabella permetta di scrivere o eliminare i diritti direttamente sulla tabella a nessuno eccetto un amministratore di sistema. È inoltre necessario tenere conto dei controlli interni che non consentono a qualcuno di creare una nuova società e quindi di addebitare gli articoli a tale società (una via per la frode). Azioni come queste richiedono sempre che le persone in due ruoli diversi approvino. Anche i controlli non dovrebbero essere tagliati a meno che una persona non inserisca i dati e un'altra approvi la spesa.

Tutte le tabelle devono avere trigger che creano record di controllo. Stai cercando di prevenire le frodi e se capita di determinare esattamente chi ha preso le azioni quando.

Nelle applicazioni finanziarie, sei molto più interessato a un sacco di processi di back-end che non sono mai visti dall'interfaccia utente. La tua prima preoccupazione è prevenire le frodi e quindi molti controlli di cui nessuno è a conoscenza sono fatti nel backend.

Non vorrei affrontare un'applicazione finanziaria di alcun tipo senza leggere i GAAP (negli Stati Uniti, gli altri paesi hanno i loro standard contabili) a fondo e avere un CPA come consulente in quanto le pratiche contabili scorrette possono portare alla prigione. Questo è un campo altamente tecnico e qualcuno senza il know-how richiesto non ha alcuna intenzione di creare software in quest'area.

La contabilità è spesso sulla verifica. Finché ti ricordi di questo e capisci la relazione tra ogni entità, è piuttosto difficile sbagliarlo.

Cercherò di elencare quanti più controlli posso ma mancherò inevitabilmente un po ', spero che sia sufficiente per iniziare a scavare da soli.

Totale addebiti == Crediti totali, questo è vero se si sta parlando dell'intero insieme di conti o di una sola transazione isolata. Se non corrisponde, hai mancato almeno un posting da qualche parte. Ecco come si regola la contabilità generale.

Crediti clienti (debiti netti sul conto di controllo) == Totale fatturati (somma totale di tutti gli importi fatturabili) - Totale ricevuto (somma totale di tutti i pagamenti ricevuti). Questo è un esempio di come i totali di transazione in termini reali di documento fisico e materiale devono essere bilanciati con il Contabilità generale (doppia voce).

Saldo bancario (in base al tuo estratto conto bancario) == Il tuo conto in banca totale per quel conto + qualsiasi assegno ricevuto che non è stato depositato - qualsiasi assegno emesso che non sia incassato. Questo è un esempio di come i conti bancari / contante con il libro mastro generale.

Come puoi vedere, ogni transazione, sottocartella, anche stock, si collega direttamente alla contabilità generale.

Se esegui test unitari, è piuttosto facile eseguire test che assicurano che questi saldi esistano ogni volta che inserisci / aggiorni le transazioni purché tu sappia cosa controllare.

Naturalmente ci sono più saldi da controllare / conteggio, ma dovresti ottenere il succo del lavoro richiesto. In sostanza, tutto si contrappone a tutto il resto, che si tratti di documenti fisici, articoli di contabilità generale, estratti conto bancari. Dovrebbe essere un perfetto equilibrio, o nei casi in cui si è pigri per affrontare l'arrotondamento, vicino alla perfezione.

Maggiore è il numero di controlli che puoi eseguire mentre lo stai sviluppando, minori sono le probabilità che tu possa sbagliare.

BTW, quando hai a che fare con l'arrotondamento, prova ad andare con i decimali invece dei galleggianti, ti farà risparmiare un sacco di mal di testa lungo la strada. : P