Base de données de comptabilité - le stockage d'une transaction

Question

Vous faites un site de jeu où l'utilisateur peut acheter des crédits de jeu et les fonds sont déposés/crédité sur le compte virtuel pour jouer un jeu de l'utilisateur, etc ... etc ..

Si vous avez un comptable pour enregistrer la transaction, il serait enregistré comme ça (peut-être un peu plus complexe, mais vous obtenez le point)

TRANSACTION 
PK_ID1 Cash  - $10 (System) 
PK_ID2 Deposit  $10 (System) 

TRANSACTION 
PK_ID3 Bank Account  - $10 (John) 
PK_ID4 Deposit  $10 (John) 

En tant que développeur, avez-vous vraiment besoin de perdre 2 disques supplémentaires? pourquoi ne pas simplement l'enregistrer comme ça ... (vous pouvez stocker des informations où les fonds provenaient, état dans d'autres colonnes sous le même dossier de dépôt)

TRANSACTION 
PK_ID1 Cash  - $10 (system) 
PK_ID2 Deposit  $10 (John) 

est-il un réel avantage de l'option # 1 sur l'option # 2 et vice visa?

EDIT: question modifiée, supprimée CR, DR et remplacée par un signe.

Answer 1

(répondre à votre question, mais aussi de répondre certains points soulevés dans la réponse de paxdiablo.)

Il n'y a rien à voir avec l'expert-comptable à la recherche dans votre base de données. Avec la double entrée, les erreurs sont faciles à tracer; c'est une comptabilité et exigence IRS, donc vraiment, vous n'avez pas le choix, vous avez besoin d'une double entrée pour tout système qui traite des fonds publics.

• (S'il vous plaît ne pas essayer de me dire ce « double entrée » est,. Je l'ai écrit systèmes à double entrée pour les banques, à la vérification des exigences) Double entrée est une méthode comptable, sur la base d'un ensemble de comptes. Chaque transaction financière est Journal Entry; Si toutes les transactions étaient réappliquées depuis le début, tous les comptes auraient exactement le même équilibre qu'aujourd'hui. Double entrée signifie que chaque transaction a un compte "À" et un compte "De"; l'argent ne quitte jamais le système ou ne pénètre pas dans le système. Chaque crédit est associé à un débit.

• Par conséquent (1) n'est pas la version "double entrée" de (2), ils ne peuvent pas être facilement comparés. La version à double entrée de la transaction de John est (une transaction financière), en termes comptables logiques:

  • De: JohnAccount A: SystemAccount Montant: 10.00 (dollars)

  • qui pourrait bien être deux lignes une table, un un crédit et l'autre un débit, les deux inserts enveloppés dans une transaction SQL.

• Voilà pour le système de comptabilité, qui est interne, et traite de l'argent. Nous avons fini. Mais vous associez en outre le système de comptabilité à un système d'achat/vente (sans l'avoir explicitement déclaré). Bien sûr, pour les dix dollars que vous avez pris à John, vous devez lui donner tout ce qu'il a acheté pour cela, et noter cela. John a acheté dix dollars de dollars de crédits de jeu, si vous suivez cela, alors oui, vous avez également besoin:

  • De: SystemGamingAccount A: JohnGamingAccount Montant: 100 (crédits)
    ou, exprimé en dollars:

  • de: SystemGamingAccount a: JohnGamingAccount Montant: 10.00 (dollars)

  • Cela aussi, peut-être deux lignes d'une table, un crédit et l'autre un débit, les quatre inserts enveloppés dans une transaction SQL.

• Pour être clair, si vous vendez des widgets au lieu des crédits de jeu, la deuxième transaction (suivi widget) serait:

  • De: Warehouse A: PublicSale Montant: 1 (widgets Et puisque vous suivez les unités dans l'entrepôt, mais pas le nombre de widgets que John Q Public a dans sa poche, c'est-à-dire deux insertions plus une mise à jour (UPDATE Part SET QtInStock = QtyInStock - 1 WHERE PartCode = "Widget"), toutes enveloppé dans une transaction SQL.

Et il y a un compte pour chaque utilisateur, à droite. Virtuel, ésotérique ou physique, c'est une entité légale, contre laquelle les transactions sont faites. Donc, ne prétendons pas que ça n'existe pas parce que c'est virtuel. Pour les jeux, un compte d'un dollar plus un compte de jeu (crédit).

Crédit/Débit

Je remettrait le CR/DB; pas CHAR (2), mais booléen.Il vous aidera plus tard lorsque la table est grande,

WHERE IsCredit = 1 

est beaucoup plus rapide que

WHERE Amount >= 0. 

Notez que avec « > = » vous devez vous assurer que chaque segment de code est codé de la même façon, pas ">" parfois. Boolean ou char n'a pas ce problème.

Answer 2

En termes de données (ce que vous demandez), non. Vous devez le stocker en tant que valeur signée. La comptabilité en partie double n'est pas quelque chose que la populace fait pour masquer les bénéfices réels de l'IRS :-)

Cela signifie que la transaction doit être équilibrée (la valeur n'est jamais créée ou détruite, juste transformée). Et il sera beaucoup plus facile d'équilibrer les transactions (et les livres) si vous les stockez simplement dans une colonne avec un signe. En termes de présentation visuelle, certains comptables peuvent les aimer dans des colonnes séparées mais la grande majorité générera des rapports avec les «négatifs» simplement indiqués différemment (comme les entourer de parenthèses).

Il se pourrait bien que (comme beaucoup d'autres choses comptables), les colonnes doubles soient reportées de nombreuses lunes auparavant. Il serait plus facile d'additionner deux colonnes, puis de soustraire le total négatif du total positif pour obtenir la position actuelle (par opposition à l'addition et la soustraction de manière intermittente). Mais c'est une supposition de ma part.

Voir aussi here.