Diseño de bases de datos de aplicaciones de finanzas personales

Question

Después de buscar una aplicación minimalista de seguimiento/presupuestación de dinero, decidí crear una para mi uso personal.

Sin embargo, no estoy seguro con parte del diseño de la base de datos. Básicamente, en este momento, tengo una tabla de entradas que obviamente almacena datos sobre cada transacción, ya sea de crédito o deuda, etc.

El dilema que tengo es que no sé si debería crear otra tabla para almacenar el el saldo actual de cada cuenta o si debería poblarlo dinámicamente restando los débitos de los créditos.

Parte de mí dice que a medida que la tabla de entradas crezca la capacidad de generar el saldo para cada cuenta será más lenta (sí, la optimización prematura es supuestamente mala), pero también parece innecesario agregar otra tabla cuando puedo calcular el datos de tablas existentes.

Gracias

EDIT: Lo sentimos puede que no haya sido claro, entiendo cómo poner en práctica cualquiera de los métodos de crear el saldo de la cuenta. Estaba mirando más las ventajas/desventajas de cualquiera de los métodos, así como cuál sería la 'mejor práctica'. ¡Muchas gracias por las respuestas!

Answer 1

Si tuviera que diseñar una aplicación de contabilidad minimalista, probablemente haría algo así

ledger 
------------- 
    key   INT(12) PRIMARY KEY 
    account_id INT(10) 
    category_id INT(10) 
    trans_type CHAR(3) 
    amount  NUMERIC(10,2) 

account 
------------ 
    account_id INT(10) PRIMARY KEY 
    created  DATETIME 
    name   VARCHAR(32) 
    ... 

category 
------------ 
    category_id INT(10) 
    name   VARCHAR(32) 
    ... 

La columna key consistiría en una fecha y un valor numérico con relleno de ceros (es decir 201102230000) donde el último 4 dígitos sería la identificación de transacción diaria. Esto sería útil para rastrear las transacciones y devolver un rango, etc. La identificación de transacción diaria 0000 podría ser el saldo de la cuenta al principio (o final) del día, y la identificación 0001 y más son otras transacciones.

La columna trans_type sostendría códigos de transacción, tales como "DEB" (débito), "CRE" (de crédito), "TRA" (transferencia) y "BAL" (balance), etc.

Con una configuración así, puede realizar cualquier tipo de consulta, desde obtener todas las transacciones de "crédito" entre una fecha determinada, hasta el saldo de la cuenta en cualquier fecha o rango de fechas.

Ejemplo: captar todas las transacciones de crédito y débito entre 2011-01-01 y 2011-02-23

SELECT ledger.*, account.name, category.name 
    FROM ledger 
    JOIN account 
    ON ledger.account_id = account.account_id 
    JOIN category 
    ON ledger.category_id = category.category_id 
WHERE (ledger.trans_type = "CRE" 
    OR ledger.trans_type = "DEB") 
    AND ledger.key BETWEEN 201101010000 AND 201102239999 
ORDER BY ledger.key ASC 

Ejemplo: captar todas las transacciones (excepto los saldos) entre 2011-01-01 y 2011-02-23 para la cuenta # 1 (ex: Hipoteca)

SELECT ledger.*, account.name, category.name 
    FROM ledger 
    JOIN account 
    ON ledger.account_id = account.account_id 
    JOIN category 
    ON ledger.category_id = category.category_id 
WHERE ledger.trans_type <> "BAL" 
    AND ledger.key BETWEEN 201101010000 AND 201102239999 
    AND account.id = 1 
ORDER BY ledger.key ASC 

Así que ahí tienes, flexibilidad y extensibilidad.

Answer 2

De hecho, estoy trabajando en esta idea solo sitio web en este momento y la forma en que he configurar mi base de datos es:

TABLE account 
    id 
    account_name 
    current_balance 

TABLE transaction 
    id 
    account_id 
    payee 
    date 
    amount 
    category 

Y cada vez que se añade una nueva transacción puedo actualizar el saldo actual de la cuenta.

FYI, espero lanzar mi sitio en un mes y si está interesado en utilizar el sitio de una persona, simplemente eche un vistazo a mi perfil.

Answer 3

Creo que una sola lectura de tabla sería mejor y permitiría una mayor flexibilidad en el futuro. Eventualmente, podría rastrear los promedios de saldo, créditos y débitos.

Answer 4

Para una base de datos personal Los sistemas de bases de datos relacionales de hoy en día son lo suficientemente rápidos como para calcular dinámicamente el saldo de varias cuentas. No necesita una columna para mantener el saldo actual. Incluso Microsoft Access es lo suficientemente rápido. Lo sé porque construí y uso una base de datos financieros personales en Access. Puede ser incluso lo que estabas buscando originalmente. Puede leer al respecto y descargarlo al http://maiaco.com/software/ledger/index.php

Answer 5

No almacene valores calculados en tablas a menos que lo necesite por motivos de rendimiento. Usaría una vista para exponer los valores calculados.