No, yo no me enojo fácilmente... lo que pasa es que a veces al hablar, puedo parecer brusco y de ahí habrá quien asuma enojo...
Más arriba te ponía un ejemplo (con código y todo), con la intención de explicarte que aunque hay múltiples ítems en principio ídénticos, ninguno caía en otra 'caja' que la suya propia, precisamente para ilustrar que lo que lo hace posible es elegir una clave única para esa 'caja'...
...en el ejemplo, la clave se formaba con "año" + los 4 digitos del año.
De igual modo debes proceder tú... Para rama principal se le debe asignar una clave única. Y luego todos los elementos bajo esa rama, deben hacer alusión a esa clave.
En realidad es algo que ya debería venir desde diseño en la propia BD. Si no es así, el código para delimitar correctamente cada caso, puede ser tortuoso, porque tendrás que verificar muchos otros factores (posiblemente no disponibles en los datos rescatados), que supondrá mayor sobrecarga, aún suponiendo que logre salir bien... o directamente no ser posible por no disponer de los datos suficientes para delimitarlo.
He abierto tu base de datos, pero hay bastantes tablas y no me apetece perder tiempo mirando la relación entre ellas, si lo tienes preferiría que pusieras un diagrama (incluso aunque sea dibujado a mano), donde se vea la relación entre todas ellas... tampoco es preciso que sea un diagrama de toda la base de datos, basta que te ciñas por ejemplo a 'cotizaciones' y muestres las tablas implicadas con esta, los campos que tiene cada una y como se relacionan los campos (los que se relacionen) de una con las otras... Después es solo extender el concepto al resto de casos.
La forma óptima pasa por un diseño adecuado de la base de datos...
Realmente lo que he visto de tu BD, dista mucho, así que intento hacerte una explicación algo en detalle pero sin profundizar (daría para un libro).
Sea una tabla llamada ventas, con estos campos:
- IdVenta: -> único, numérico, autoincrementable, "primary key", otras tablas se relacionan con esta clave.
- IdArticulo: -> Foreign key, relacionado con la tabla artículos. Realmente este campo puede ser una lista de artículos (cada compra no es de un solo artículo) en cuyo caso no debe aparecer como tal, si no como un método "GetArticulosPorVenta(IdVenta)"
- IdComprador: -> Foreign key, relacionado con la tabla artículos.
- IdVendedor: -> Foreign key, relacionado con la tabla artículos.
- IdEnvio: -> Foreignkey, relacionado con la tabla envios. Este dato se rellena cuando el vendedor relice el envío.
- IdMetodoEnvio: -> Foreign key, relacionado ocn una tabla ServiciosDeEnvio, es un valor elegible por el comprador, de una enumeración... esto es muy dependiente de las zonas geográficas y los sevicios que allí se den. pero generalmente existirá algún tipo de prioridad (estandar, urgente y muy urgente), etc.. Este dato se rellena cuando el comprador elige un método de envío entre los disponibles. Al final hablo de la tabla Mensajeros y ServiciosDeEnvio.
- EnvioConjunto: En esta venta varios artículos se envían juntos en un mismo paquete. (esto se relaciona con IdArticulo, más abajo hablo sobre esto)
- FechaVenta: -> datetime, tomada con la función 'now', en el momento de validar la compra.
- FechaEntrega: -> datetime, fecha prevista de entrega, aproximada... posiblemente sea la suma de la fecha de compra o más claramente de la fecha de verificación del cobro, + TiempoLogistica (dependiente del artículo, tamaño, existencias, origen) y destino del comprador (si vive en la ciudad, en el país, o en el extrajero) y posiblemente del método de envío elegido. Este dato se rellena automáticamente cuando se eleige l método de envío...
- Estado: -> valor de enumeracion: problema, comprado, pagado, procesando, enviado, recibido, eliminado (retirado a una base de datos de backup, cuando ya tiene una antigüedad de x semanas/meses tras ser recibido). Problema es el resto de estados pero en valor negativo, indica que en ese estado positivo se registró un problema, así se sabe que es un problema y donde recáe el problema.
En tu Bd, para esta tabla, usas ncli, usa mejor IdCliente para señalar que es una clave única (Id)... y usa el nombre completo, IdCliente, IdComprador, no IdCli, ni IdC... no se ahorra nada por omitir 8 caracteres en el nombre de un campo.
A tu tabla le falta (como mínimo) el IdArticulo...(pero esto tiene miga, me extiendo más abajo, primero por pasos) cada venta es única, pero diferentes ventas pueden tener un mismo artículo...
Una posible explicación es que tienes una tabla llamada Ventas_Detalles, bien puedes trasladar ahí los detalles de esta tabla, pero en ese caso, en esta tabla debe haber unica y exclusivamente el IdVenta y pocos campos más (también Ids)... es decir esta tabla sería un 'array' un índice donde buscar la venta y con ella ir a la tabla detalles... sin embargo lo veo redundante. porque en la tabla detalles, no va a haber repetida ningún idVenta, luego aquella es un clon de esta, pero disperasando unos datos en una y otros en otra...
Una misma venta puede contener varios artículos, por lo que en realidad, es mjor opción eliminar IdArticulo de la tabla ventas, pero disponer de un método apuntando a otra tabla... ahí si podría llamarse VentaDetalles, pero para nada los campos que tu tienes... y considerar que cada venta tiene detalles (como mínimo un artículo comprado) y para conocer los artículos comprados se debe consultar dicha tabla: "select IdArticulo from VentaDetalles where idVenta = EstaVenta" (Ventas.IdVenta: aquí se pasa el idVenta por el que estás interesado), esto devuelve todos los registros de artículos asociados a una venta específica, artículos que luego se colocan como hijos de la venta en el treeview.
Tabla VentaDetalles:Cada registro de compone de dos referencias. Una al artículo y otra a la venta. De esto modo multiples artículos comprados apuntarán a la misma venta.
- IdArticulo: foreign key, se relaciona con un único artículo.
- IdVenta: foregin key, relaciona a este artículo con una compra específica.
opcional
- IdVendedor: foreign key (abajo del todo después del pseudocódigo comento esta opción)
La otra opción es más cara y supone un mal planteamiento de la base de datos, ya que exige que si se compran varios artículos, exista un registro de compra por cada artículo... Es mla planteamiento por:
- De entrada exige sobrecarga de memoria, la base de datos crece, una compra elegante solo requiere un registro de venta + 2 ids por cada artículo comprado, frente a tantos registro de venta como articulos comprados en una sola venta.
- Como cada venta, tiene su primarykey, esta resulta inútil para relacionar todos los artículos comprados con una sola venta (que es lo que te pasa). Supone entonces que al comprar debes crear una referencia única para cada venta (que es justamente lo que es un primary key, que se crea sola y de la que te desentiendes, pero aquí por tu solución te la debes currar tú), y en cada registro de venta (para una misma compra) debe constar esa referencia de venta...
- Supone además crear más métodos... para consultas y actualizaciones.
- No existe una tabla donde consten todas esas 'referencias únicas, sino que resulta de 'explorar' intensivamente dicha tabla 'ventas' (intensivamente=sobrecarga inútil).
Entonces la existencia de la tabla Ventas y los campos declarados sugiere que además deben existir las siguientes tablas (más las derivadas de esas):
Articulos, Compradores (clientes), Compras, Vendedores, Almacen, Pedidos, Mensajeros, ServicioDeEnvio, Envios, Imagenes...
La tabla articulo (producto): Breve descripción: Sobre ella recáe el añadir o eliminar artículos (siponibles a la venta), y actualizaciones: modificar precio, descripción, nombre imagen. Se relaciona además de con: Ventas, Clientes y Vendedores con Almacen y Pedidos.
Respecto de pedidos, hace falta saber si los artículos son todos de un solo vendedor o cada vendedor expone sus propios artículos (asumo esto último si existen IdVendedor, es que hay más de uno), es decir que no es para empresa que vende si no para una empresa que gestiona compra-ventas, ellos mismos solo son mediadores y no venden artículos propios. Esto implica que esta tabla puede ser muy diferente según el caso... haré una somera descruipción de cada caso aparte:
Si hay multiples vendedores, la tabla almacén, Pedidos y otras sobran, ya que será el propio vendedor el encargado de tales gestiones y escapa, aquí todavía se podrá mantener la tabla envíos, donde el comprador indique fecha de pago (si no es inmediato y recibido cuando llegue a su casa el paquete, y el vendedor indique cobrado, enviado... aunque estos estados deben ser opcionales, porque unos y otros suelen olvidar actualizar tales datos.
Tabla Articulo: Vendedor Absoluto: por ejemplo una ferretería, un supermercado.
- IdArticulo: -> único, numerico, autoincrementable, primary key,
- IdImagen: -> foreignKey --- se relaciona con la tabla Imagenes. Un valor 0 indica que no posee imagen asociada al artículo.
- Nombre: -> texto, 64caracteres máximo (aprox.). Nombre simple que el cliente verá como título del artículo.
- Referencia: ref + hash del nombre + IdArticulo , ejemplo: refAD34B2-00345. Este se recalcula solo cuando cambia el nombre. Y solo sirve para ventas futuras, para las pasadas ya no importa.
- Descripcion: --> Texto más largo y más detallado, que descibra el producto.
- TiempoDeManipulación: -> numerico byte, indica el tiempo aproximado (en días) que se tarda en envolver y enviar dicho artículo. No es lo mismo un reloj, que un armario de 4 puertas. En caso de un supermercado, o una ferretería esto es inmediato, se lo lleva el propio comprador, luego este campo sobraría.
- Peso: -> numerico, entero . peso aprox en decimas de kg. es decir algo de valor 1, señala que psa 100 gramos, algo de valor 10 pesa 1kg. (para evitar operar con números reales), si requieres dos decimales, es volver a plicar lo mismo.
- Dimensiones: -> 20 caracteres en la forma xxx'xx-yyy'yy-zzz'zz largoXanchoXalto en cm. con 2 decimales. Un comprador querrá saber las medidas de ciertos artículos. si empieza por un valor que no es dígito, se considera que no se proporciona medidas, no uses espacios al caso, relena con ceros, ejemplo: 001'23-030'00-102'40.
- Existencias: -> numérico Cantidad restante en stock. ---> Debe relacionarse con tabla Almacen
- AlarmaExistencias: -> numérico, Cuando se compra un artículo, existencias se reduce en 1 8la cantidad comprada), y se verifica si es menor o igual que este campo, si es así, dispara un evento a "Pedidos".
Tabla Articulo: Múltiples Vendedores: La empresa es un intermediario entre el comprador y vendendor (tipo eBay).
Como decía más arriba para la descripción de artículos, si cada artículo es provisto por un vendedor concreto, forzosamente es obligado que esta tabla incluya unos campos y no requiere otros. Del mismo modo unos campos los podrá modificar el vendedor otros son automáticos (como los ids) y según la necesidad de destino, otros pueden variar...
- IdVendedor: -> foreign key, a fin de que un vendedor pueda tener acceso a su artículo en venta y hacer las modificaciones que precise.
- IdArticulo: -> único, numerico, autoincrementable, primary key,
- IdImagen: -> foreignKey --- se relaciona con la tabla Imagenes. Un valor 0 indica que no posee imagen asociada al artículo.
- Nombre: -> texto, 64caracteres máximo (aprox.). Nombre simple que el cliente verá como título del artículo.
- Referencia: ref + hash del nombre + IdArticulo , ejemplo: refAD34B2-00345. Este se recalcula solo cuando cambia el nombre. Y solo sirve para ventas futuras, para las pasadas ya no importa.
- Descripcion: --> Texto más largo y más detallado, que descibra el producto. Un libro puede llevar el nombre de autores o ISBN, en cambo un pantalón puede señalr si es para señora y la talla.
- TiempoDeManipulación: -> numerico byte, indica el tiempo aproximado (en días) que el vendedor señala tardar en envolver y enviar dicho artículo. Este tiempo se supone que es añadido a la fecha de verificación del cobro.
- Peso: -> numerico, entero . peso aprox en decimas de kg. es decir algo de valor 1, señala que psa 100 gramos, algo de valor 10 pesa 1kg. (para evitar operar con números reales), si requieres dos decimales, es volver a plicar lo mismo.
- Dimensiones: -> 20 caracteres en la forma xxx'xx-yyy'yy-zzz'zz largoXanchoXalto en cm. con 2 decimales. Un comprador querrá saber las medidas de ciertos artículos. si empieza por un valor que no es dígito, se considera que no se proporciona medidas, no uses espacios al caso, relena con ceros, ejemplo: 001'23-030'00-102'40.
- Existencias: -> numérico Si el vendedor dispone de más de 1 igual a la venta, en otro caso vale 1. Esto no requiere almacén Debe relacionarse con tabla Almacen
- Otros campos que pudieren ser importantes según el cliente del programa.
Tabla Compras:Esta tabla tiene el mismo propósito para los Compradores que para los Vendedores la tabla Ventas.
En realidad bien diseñado, Ni Ventas ni Compras deben existir, si no una llamada Transacciones donde el vendedor hace consultas de sus Ventas (esto es, ventas sería una clase con varios métodos, lo mismo que compras, que realizan consultas a la tabla transacciones, una spreguntando con IdVendedor y otros con el IdComprador).
Que se le llame tblTransacciones a la tabla, no cambia más que el nombre, los campos vienen siendo los mismos, solo lo aleja de la idea de 'pertenencia' o asociación a 'vendedores'.
Tabla Imagenes:Contiene el id de cada imagen y la ruta donde localizarla.
Hay quien guarda la imagen en la base de datos, pero eso hace una base de datos gigante y la expone a fallos y problemas de rendimiento. Por ejemplo cuando se debe restructurar una base de datos, mover imágenes (registros conteniendo imágenes) es pesado...
Solo tiene dos ventajas guardar imágenes en la BD: resulta tan infranqueable como la propia BD, la posibilidad de extravío se limita al extravío de la propia BD. En su contra lo mismo, si están en la BD y esta revienta, se piuerden todas, si están en ficheros sueltos en una carpeta, se perderá la que se pierda el resto se mantiene.
Aún así si uno decide guardarimágenes en una BD, sugiero que es aBD, solo aloje imágenes y nada más...
- IdImagen: -> único, numerico, autoincrementable, primary key, Una imagen inexistente debe tener id=0, una imagen ilocalizable se debe devolver mediante un método que al final entregue -Id . Así cuando se localiza una imagen si se devuelve un valor menor que 1, implica que (0) ó no tiene (-0) ó que la imagen no está en la ruta esperada, fue eliminada, renombrada, etc...
- Ruta: -> texto, 512 caracteres (los 248 para la ruta + los 260 para el fichero).. seguramente no se usen... una forma de dejarlo más corto, es dejar rutas relativas, para el fichero, es decir la carpeta es fija y conocida en la instalación, por tanto basta guardar el nombre d ela imagen, y al caso entonces se puede crear un hash para la imagen como nombre basado en el IdArticulo y Nombre del artículo, + la extnsión de la imagen, con lo que se reduce a apenas 32-40 caracteres: ..\Imagenes\articulos\*.*
Las tablas Compradores, Vendedores, Mensajeros vienen a ser casi idénticas, solo cambia su nombre. Y la tabla que s eles asocia: A Vendedores con Ventas, a Compradores con Compras, a Mensajeros con Envios y a los previos también con Envios indirectamente a traves de compras o ventas.
Otras tablas:
Almacen: Stocks de entrada.
Pedidos: Stocks de compra.
Mensajeros: Datos de empresas de enviós. (es idéntico a compradores y vendedores)
ServiciosDeEnvio:
- IdModeloEnvio: sería su principal campo, donde se relaciona la empresa IdMensajero con un tipo particular de envio..
- Prioridad: estandar, urgente, muy urgente,
- Lejania: local, nacional, internacional, etc...
- MedidasMaximas (como campo más arriba de 20 caracteres)
- PesoMaximo: (como campo más arriba, para evitar decimales)
- Precio: Lo que cuesta este servicio si cae dentro de las exigencias.
- Sobrecoste1: Precio extra por algún detalle, por ejemplo si sobrepasa de 12, pero no llega a 20, x por cada kilo o fracción extra. (el 1 es porque puede haber más sobrecostes).
En realidad el diseño final, depende mucho de los requisitos del que reclama el programa (al margen de la propia especificación), unos te dan rienda suelta, y otros reclaman cosas muy específicas... y a veces absurdas.
Y bueno, si esto lo tuvieras más o menos así... teniendo perfectamente relacionado cada cosa con su Ids, se puede usar para rescatar de la BD, los registros asociados.
Entonces, con el diseño mostrado para la clase ventas, por ejemplo podrías tomar cada registro de venta de un vendedor y luego buscar los artículos de cada venta...
Evidentemente la vista del treeview, contendrá lo que se quiera consultar, pero se debe ser coherente... en el ejemplo se mstraría como raíz los datos del vendedor, como hijo de este ítem cada una de las ventas, y bajo cada venta cada uno de los artículos de dicha venta.
(podría reducirse desde todas a solo las que haya a partir de 'x' fecha, o solo las 'y' últimas)...
' se omite cualquier tratamiento posible de error, solo pretende ser ilustrativo de la forma correcta de proceder
Funcion VistaVendedorTodasSusVentas( numerico esteVendedor, string conectionString)
Resulset: rsVendedor, rsVentas, rsArticulo
Vaciar Treeview
AbrirBD(conectionString)
rsVendedor = Select From tblVendedores where IdVendedor = esteVendedor
Añadir al Treeview como raíz el registro IdVendedor
rsVentas = "Select all from Ventas where IdVendedor = EstevendedorQueConsulta", y luego en un bucle
Por cada registro de este rsVentas
Añadir al treeview esta venta con clave IdVenta, bajo raiz. ('strinnizada', añadiendo algún caracter para que no empiece por dígito, por ejemplo el nombre del vendedor, o simplemente key = "v" & IdVenta
rsArticulos = "select IdArticulo from VentaDetalles where idVenta = EstaVenta"
For cada registro en rsArticulos
Articulo = "Select * From tblArticulos where IdArticulo = registro"
añadir al treeview como hijo de IdVenta, los detalles del artículo que interesen..
siguiente
Siguiente
cerrar BD
Fin funcion
Puede que a primera vista te parezca mucha sobrecarga tantas consultas, pero se limita a lo preciso en cada caso, no a obtener un tocho de regstros que luego no se requieran, o no se correspondan, como resultado es más eficiente, son llamadas breves y rápidas, porque son muy acotadas.
Si Access no se comportara bien (no debería ser problema con las versiones actuales que están muy optimizadas, otro cantar sería versiones de los 90), en esos casos quizás convenga añadir a la tabla tblVentaDetalles el campo IdVendedor, y así se podrían rescatar todos de la BD, de una sola vez, a la entrada de la función (en vez de en el bucle), y en el bucle luego revisar cuales correponde al caso. para aligerar esto, con cada añadido al treeview, sería acorde ir eliminado del resulset los registros ya metidos, así la búsqeuda sería más corta cada vez en el bucle... es decir estamos remplazando la sobrecarga en el servidor (donde consta la BD), por sobrecarga en el entorno de la vista (el equipo del cliente)...
Otra opción a considerar en el ejemplo, sería mostrar el vendedor en raíz, y luego bajo el las ventas... y solo cuando el usuario pulse en dicha venta es cuando se consulta los artículos para dicha venta y se muestra en otra ventanita aparte (o en la misma ventana bajo el treeview principal, otro treeview, o un listview a la derecha, etc..).
Esto es aún más acertado, porque aligera aún más la BD de carga de trabajo, solo se reclamarán los artículos de aquella venta para la que el usuario quiera ver los detalles.Y bueno ya sale un mensaje largo así que corto...
Mostrar Mensajes
