Diagramación Mysql, Ingresos y Egresos

[minkweb]

Bueno, les planteo este problemilla de diagramación de bases de datos, esto es para un sistema de registro de entrada y salida de dinero (Ingresos y Egresos)

PRIMERA DUDA
Actualmente estoy haciendo todo en una tabla, se llama ”movimiento”, me pareció a mi algo poco funcional tener 2 tablas ”egresos” e ”ingresos” si tienen la misma estructura, entonces en la tabla movimiento tengo un campo ”tipo_movimiento” que puede ser egreso o ingreso
¿Esto es correcto hacerlo en 1 tabla o debo hacerlo en 2 tablas?

SEGUNDA DUDA
Basado en el esquema de 1 tabla para movimientos de dinero, tengo que tener en cada uno de los registros de la tabla “movimiento” un id que relaciona con otra tabla con los detalles, un ejemplo

Se registra en la tabla ”movimiento”, un egreso de 100$ usd por un servicio adquirido, se registra el concepto, la fecha, la cantidad de dinero y el id de la tabla ”proveedor_servicio” (donde están los datos de ese proveedor).

Con ese ejemplo todo bien, el problema es que estoy usando llaves foráneas, teniendo en cuenta que no solo seria la tabla de ”proveedor_servicio”, también seria ”cliente” y pueden que a largo plazo sean mas, esto pienso yo me genera un problema para tener un campo con llave foránea a diversos campos de diversas tablas.
¿Cómo solucionarían este problema?

[gnzsoloyo]

esto pienso yo me genera un problema para tener un campo con llave foránea a diversos campos de diversas tablas.
¿Cómo solucionarían este problema?

Ese problema de la convergencia entre proveedores y clientes debería darte ya la pista: No puedes tener una tabla movimiento, porque no sólo las entidades Ingreso y Egreso son distintas, sino que sus dependencias también lo son.
El problema es que estás confundiendo entidades con tablas, y no son lo mismo.
El hecho de que dos tablas sean iguales en campos, y tipos de datos, no significa que representen lo mismo. Y si no representan los mismo, si representan entidades diferentes, son tablas distintas.
Punto.

Empieza de nuevo y pon dos tablas diferentes una para egresos y otra para ingresos.

[minkweb]

Vale, eso soluciona el primer problema, pero el segundo me queda confuso, igual cualquiera de las tablas egresos o ingresos pueden llegar a tener relación con mas de una tabla.
¿Me veo obligado a crear ingreso_cliente, ingreso_servicio, egreso_servicio y las que se presenten? me preocupa la escalabilidad y tener luego muchas tablas..

Cual seria una correcta solución?

[gnzsoloyo]

Todo atributo mandatorio (obligatorio) cuya clave esté presente en otra tabla como PK debe ser creado como FK.
Tu problema en realidad no es la escalabilidad, es la consistencia. La escalabilidad es manejable, pero datos inconsistentes y faltos de integridad referencial, no.

Por otro lado, ¿te preocupan una media docena de FK? Tengo bases donde ciertas tablas tienen más de veinte distintas, y son bases de datos que almacenan datos de clientes de todo un país, y no por tener esa cantidad de claves tienen problemas de escalabilidad.
Si las definiciones de las tablas, las relaciones y las restricciones están bien construidas, tu unico problema consistirá en hacer que las aplicaciones hagan bien las inserciones.