Modelado recomendado

Ejemplos completos de tablas, FKs y reparto entre modulos

Esta pagina resume como deberian enlazarse los modulos mas importantes sin duplicar datos ni mezclar responsabilidades.

ENTIDADES como maestro comun

ENTIDADES debe ser el maestro base de terceros. Todo lo comun debe vivir aqui.

ENTIDADES_Entidades
  Id
  EmpresaId
  Tipo
  Nombre
  Nif
  Email
  Telefono
  Estado

EntidadDetalle
  Id
  EntidadId
  Web
  Observaciones
  DatosFiscales

EntidadContacto
  Id
  EntidadId
  Nombre
  Cargo
  Email
  Telefono

EntidadDomicilio
  Id
  EntidadId
  Direccion
  Ciudad
  Provincia
  Pais
  CodigoPostal
Cualquier modulo que necesite un tercero debe enlazar con EntidadId o usar el servicio de ENTIDADES.

PROVEEDORES como perfil especifico

PROVEEDORES no debe repetir la ficha base. Debe guardar solo lo que hace especifico a un proveedor.

PROVEEDORES_Proveedores
  Id
  EntidadId
  EmpresaId
  CodigoProveedor
  FormaPago
  DiasPago
  CuentaContable
  ObservacionesCompra
  Activo

Relacion recomendada

builder.HasOne<Entidad>()
    .WithMany()
    .HasForeignKey(x => x.EntidadId)
    .OnDelete(DeleteBehavior.Restrict);

La ficha sigue siendo de ENTIDADES. PROVEEDORES solo añade perfil y logica propia.

COMPRAS sobre PROVEEDORES y PRODUCTOS

COMPRAS debe apoyarse en maestros existentes y guardar solo su operativa.

COMPRAS_Pedidos
  Id
  EmpresaId
  ProveedorId
  Fecha
  Estado
  Total

COMPRAS_PedidoLineas
  Id
  PedidoId
  ProductoId
  Cantidad
  Precio
  Descuento

COMPRAS_Recepciones
  Id
  PedidoId
  FechaRecepcion
  Estado

COMPRAS no debe guardar una copia del proveedor ni una copia del producto.

PRODUCTOS como catalogo

PRODUCTOS debe ser dueño del catalogo, categorias de producto, variantes y atributos.

PRODUCTOS_Productos
  Id
  EmpresaId
  Codigo
  Nombre
  CategoriaId
  Precio
  Activo

PRODUCTOS_Categorias
  Id
  EmpresaId
  Nombre

PRODUCTOS_Variantes
  Id
  ProductoId
  Talla
  Color
  Stock

Configuracion EF recomendada

Conviene separar entidad y configuracion EF.

public class PedidoCompraConfiguration : IEntityTypeConfiguration<PedidoCompra>
{
    public void Configure(EntityTypeBuilder<PedidoCompra> builder)
    {
        builder.ToTable("COMPRAS_Pedidos");
        builder.HasKey(x => x.Id);

        builder.Property(x => x.Estado)
            .HasMaxLength(40)
            .IsRequired();

        builder.HasIndex(x => new { x.EmpresaId, x.Fecha });
    }
}

Relaciones que suelen dar problemas

1. Maestro duplicado

No guardes nombre, email o telefono en varios modulos si ya existe un maestro comun.

2. FK sin criterio

No relaciones por texto o por codigo de pantalla si realmente necesitas una FK a una entidad estable.

3. Todo en el mismo modulo

No metas compras, proveedores y maestro de terceros en una sola tabla gigante.

Si el modelo esta bien repartido desde el principio, migraciones, hooks y permisos son mucho mas sencillos de mantener.