Crear una factura sencilla!

[gnzsoloyo]

Los criterios aplicados pueden estar, cmo dices, basados en conceptos de contabilidad, pero no se los puede aplicar directamente al diseño de las bases de datos. El modelo E-R tiene ciertas reglas que deben cumplirse para conservar y asegurar la consistencia de datos, evitar la redundancia innecesaria y mantener la integridad referencia.
La historicidad de los precios no se adminisrta poniendo los precios unitarios dentro de la factura, eso es un error grarvísimo que lleva a la inconsistencia. Para resolver el problema de la evolución histórica de los precios se hacen los diseños de la estructura de stock que los soporte.
El hecho de hace pocas tablas, como pareces suponer, no implica hacer ni bases más rápidas, ni más eficientes, ni mejores performances. Muy posiblemente lo contrario. Se deben crear tantas tablas y relaciones como sea necesario para un sistema dado. Sin necesidad de usar VisualFox (como supones), una base de datos creada en SQL Server para administrar un supermercado, puede necesitar un diseño de más de 500 tablas... y eso ni siquiera es complicado.
Por otro lado, el planteo de las modificaciones de clientes, también se considera históricamente, pero si lo razonas, un cliente sólo puede cambiar de nombre por dos razones: 1) Se ingresó mal de entrada, con lo que la correccción debe también corregir las facturaciones ya realizadas., y 2) Porque la sociedad cambia de nombre de fantasía... pero el titular se mantiene. Cuando el titular cambia, entonces no es el mismo cliente y no corresponde "actualizaciones".
Creo que estás mirando el problema desde la optica del contador o del programador. No lo estás haciendo como analista, arquitecto de datos, o DBA .