Otro caso es el que mencioné en el primer comentario. si tenemos una tabla de pagos de caja, con los campos
Id, Fecha, TipoPago,..., ValorEfectivo, ValorCheque1, Banco1, ValorCheque2, banco2, ValorTarjeta1, banco3, ValorTarjeta2, banco4...
cómo se realizaría una consulta donde deba calcular los totales por cada tipo de pago y las respectivas comisiones de las tarjetas por cada banco? es algo bien complicado, no crees?
No, definitivamente, nunca estuve de acuerdo con esto. Si vieras los líos que a veces hago para normalizar.
Pero ese ejemplo, si me permites o permiten es un caso de mal diseño, más allá de la desnormalización.
La técnica que solía usar mi profesor de la facultad era proponer una supertabla con todos los datos de una sola transacción y luego dividirla en tablas con entidades bien formadas y luego normalizarlas. Es una técnica interesante para enseñar.
Lo primero que se debe hacer es separar las entidades. No puedes mezclar datos de entidades diferentes en la misma tabla o vas mal.
Pero genriquez, yo me refería más a las buenas prácticas de codifciación en Delphi, más allá de las definiciones de datos. Igual, también hay prácticas aconsejables en esto.
Hola, creo que es interesante y práctico lo que propones CRAM, sin embargo lo que yo digo es que desnormalizar trae lios a la hora de utilizar Delphi, no quiere decir que no se pueda hacer, sino que las herramientas de Delphi están diseñadas para bases de datos normalizadas y es mucho más rápido y fácil cuando están bien normalizadas.
En mi caso particular, procuro no utilizar (Mientras sea posible) autoincrementales, las claves siempre son únicas y procuro no generar información redundante, así es más sencillo utilizar Delphi.
Para aclararte o aclararme el concepto, me gustaría saber cómo haces el manejo de los autoincrementales cuando creas un Form? no te presenta algunos inconvenientes al momento de obtener el ID autogenerado? (Asumiendo que utilizas un dataset conectado a la base de datos)
No entiendo la conexión entre la creación del form y los autoincrementales. Por favor explícame, que es algo que no me hago la idea.
A mí lo único que me trajo de problemas los autoincrementales es que aun haciendo rollback el generador ya se incrementó igual y queda un hueco en la numeración, esto puede ser indeseable en el caso de usar el mismo número, por ejemplo para la numeración de una factura emitida. Es necesario volver atrás. En caso de generar el autoincremental en otro momento (no al insertar) se desconoce el id de la cabecera y no puedes relacionar los detalles de la factura. Pero, no es un gran problema.
El problema es que si no usas autoincrementales para las relaciones, la otra salida de enumerar es: o almacenando en el sistema el último número (te mata en ambientes con más de un cliente) o buscar el máximo valor de la tabla que termina en bajar el rendimiento, ya que MAX debe leer toda la tabla, al igual que COUNT, etc. (Al menos en Firebird).
Volviendo al tema de las prácticas no aconsejables. Ya que este hilo se hizo más amplio, quiero agregar algo.
Una práctica que hace poco casi me hace arruinar un trabajo casi terminado es el hecho de llamar desde un método controlado por un evento (por ej. OnClick) otro método que se dispara normalmente por un evento diferente (OnChange, de un TEdit) solo para evitar reescribir código. Sin querer oculté funcionalidad.
Es casi seguro que cambie esta práctica por utilizar como se debe los métodos ligados a eventos lo más puros posibles y crear procedimientos con funcionalidad común en el area de procedimientos privados y llamarlos como se debe.
El tema es que Yo incluso, ordeno los métodos "event-driven", de los públicos y de los privados, y los separo con grandes líneas de comentarios y si es posible con el uso de regiones. Además, suelo llamar casi siempre los controles comunes de igual manera (Ok, Cancel, por ejemplo)
nadie lo hace, pues todo está bien 
Todos sabemos, que no existen programas perfectos.
