Maestras y submaestras


([N2] jpamiesb_1712) #1

Muy buenas
Una pregunta quizas un poco tonta, cuando trabajo con V6, la tabla FAC-VTA-CAB (Facturas de venta cabecera) la pongo com submaestra de CLT (Clientes) que es submaestra de EMP (Empresas) que es maestra y la tabla FAC-VTA-LIN (Facturas de venta lineas) la pongo como submaestra de FAC-VTA-CAB
¿ Que me aconsejais para V7 ? Hacer lo mismo, o bien cambiar el sistema
Gracias anticipadas
Catarso (Juan)

Un dia mas, un dia menos
Para cuando dice que lo quiere......................................jajajajaja


([N1] Pepeto) #2

Hola Catarso,

En primer lugar, no quiero ser yo quien te diga que esa no es la estructura ideal, porque en esta vida, todo es relativo, y nadie mejor que tu para saber el uso posterior de una estructura como esa.

Pero lo que si te digo, es que NO es mi estructrura ideal, no entiendo que beneficios te puede aportar el que la tabla FAC_VTA_CAB sea submaestra de clientes, si la numeracion de la factura la vas a tener que calcular, porque no te vale la que se genera automaticamente.

Yo te aconsejaria todas las tablas "Maestras", pero como he dicho, quiza hay cosas que no veo en el planteamiento y que pueden afectar posteriormente a un analisis como ese.

un saludo.
José Luis
http://www.ascsl.com


([N2] jpamiesb_1712) #3

@pepeto
Si todos usamos mestras, para que las sub-maestras
De otra forma el control lo tendremos que hacer nosotros
Saludos
Catarso (Juan)

Un dia mas, un dias menos
Para cuando dice que lo quiere .......................................................jajajajajajaja


([N1] Pepeto) #4

Hola de nuevo,

En primer lugar, cada uno tiene su forma de programar y sus pequeños vicios y manias.
No es que no usemos submaestras, es que este tipo de tablas considero que tienen un uso muy particular, y las utilizo solo en determinados casos.

En cualquier caso, has pedido un consejo, y este es el mio, que no quiere decir que sea el mejor y que tenga toda la razon.

Para saber que tipo de tablas debes usar, no hay nada como la experiencia, y el conocimiento del analisis estructural y la funcionalidad que queremos conseguir.

Y en base a eso, mi opinion es solo eso, una opinion. Pero la decisión final es tuya y solo tuya.

un saludo.
José Luis
http://www.ascsl.com


([N4] mperez) #5

Hola Juan, como verás hay opiniones y gustos diversos y todas son válidas si eres consecuente con lo que estas haciendo.

Quizás encuentres aquí algo aclaratorio, aunque si las haces todas maestras, desde luego nunca te equivocarás.

Por defecto Maestras.

SUBMAESTRAS Solo cuando sean líneas o casos similares.
Por ejemplo Lineas de Albaran, de Pedido, de Factura , de Presupuesto
¿Por Qué? El Indice Código de una tabla maestra se compone de un enlace a una tabla Maestra mas una segundo campo. Si este es Siguiente al última, tendremos gestionada de forma automática la gestión de líneas.
Hay otros casos que nos pueden interesar, pero los dejaremos para más adelante. Por ejemplo en una estructura Paises, Provincias, Ciudades y que una vez localizado un Pais, el siguiente localizador nos muestre solo las provincias y despues las ciudades. De http://mpoliver.wordpress.com/2008/01/29/%C2%BFcomo-definir-los-tipos-de-tablas/


([N1] VictorMC) #6

@Todos.
.
En mi experiencia las tablas submaestras cumplen cabalmente con su cometido.
.
En mi humilde opinión no recomendaría utilizar todas las tablas como tipo maestras... creo que en varios casos NO se necesita identificar de manera única un registro por ID o código.

Tengo varios casos que no podría poner en este lugar... que NO se resuelven de mejor manera que con submaestras...
.
No me imagino para que nos sirve un código de una línea de detalle de una factura algo como: Código o ID =83277 cuando como submaestras quedaría: Código o ID = 1 (ya que en cada nuevo maestro, el ID o código se vuelve a reiniciar)
.
Así otros casos como: presentaciones de artículos, entre muchos más...
.
Muy diferente es el caso de los Clientes o las Facturas donde definitivamente se requiere conocer de manera única cada registro en toda la base de datos.
.
Por lo tanto mi sugerencia es esta:
.
FAC-VTA-CAB = Maestra
CLT = Maestra
EMP = Maestra
FAC-VTA-LIN = Submaestra
.
Saludos desde México
Víctor Martínez C.
www.livesoftmx.com
empresa@livesoftmx.com
Skype: livesoftware


([N4] mittosoftware) #7

Lo de las submaestras no es un estándar de desarrollo. Eso me hace dudar sobre como será cuando quieras portar tu BD Velneo a otra plataforma, o con el acceso ODBC desde otro lado.
.
Si es algo que no es absolutamente necesario, cuando con un poquito mas de esfuerzo de inicio, tienes mas flexibilidad a futuro, especialmente cuando tu sistema es medianamente complejo y puede crecer, pues sinceramente no le veo que sea tan aconsejable su uso, salvo en casos que estes 100% seguro que tu sistema no crecerá en requerimientos mas ni necesitará otro tipo de conectividad a futuro que los que ya tiene ahora (al menos en lo concerniente a esa submaestra) .
.
Un ejemplo que se me ocurre para ilustrar lo que digo.
Albaran-LINEA = Submaestra
.
¿Que tal si a futuro las lineas del Albarán necesitaran plurales? Numeros de serie de cada código vendido (20 lamparas modelo XXX eran una sola si hablamos de lo económico, pues tienen el mismo precio unitario, pero a partir del 2013, se necesitarán plurales para registrar el número de serie y la fecha de caducidad de cada una de las 20 lámparas).
.
Es solo un ejemplo de los muchos que pueden aparecer, donde tu submaestra de pronto tiene la necesidad de plurales. ¿Se entiende?
.
Quizá quienes usan las submaestras, lo hacen, en el escenario de usar solo Velneo, y seguro es válido allí. Pero eso si, tomar en cuenta que en el mundo actual del desarrollo de software es muy competitivo y cambiante, donde la integración, la interoperabilidad y la capacidad de comunicación con otros equipos de desarrollo, son cosas demasiado importantes, y justo para eso ayudan los estándares, ademas de para prevenir muchos dolores de cabeza a futuro, cuando se trate de la escalabilidad del sistema o nuevos requerimientos.


([N4] mperez) #8

Disculpa Cesar : Las tablas Submaestras, pueden tener perfectamente plurales. Siguen teniendo un Id, de Clave única.

http://velneo.es/info_v7_78_es/velneo_vdevelop_v7/proyectos_objetos_y_editores/proyecto_de_datos/tabla/tipos_de_tabla


([N4] mittosoftware) #9

Bueno, quiza me confundí con los históricos, ahora que reviso la doc de Velneo, mea culpa. Pero aún así, tampoco me parece óptimo manejar plurales con una llave primaria compuesta de 2 campos, es una complejidad innecesaria cuando toque crecer al sistema.
.
Lo otro, la supuesta gestión de líneas, no la veo. Así a la rápida, imaginen que se crean 10 lineas de factura, pero tienes que eliminar la 4ta línea antes de confirmar la transacción, pues se te va al garete la numeración secuencial de líneas, ¿Cierto? Y se podrían buscar muchos casos mas.
.
En mi opinión, son demasiadas cosas que se te podrían complicar a futuro por un pequeño ahorro de tiempo ahora (caso similar lo de querer usar campos modificables por el usuario como llaves primarias). Siempre es preferible trabajar un poco mas en tiempo de Análisis y Diseño, e incluso en la programación, pero dejar la aplicación lo mas robusta y escalable posible.


([N2] jpamiesb_1712) #10

Hola a todos
Muchas gracias por vuestras aportaciones
Saludos
Catarso (Juan)

Un dia mas, un dia menos

Para cuando dice que lo quiere...................jajajajajajajaja


([N4] mperez) #11

Cesar, te ruego que no elucubres, sino que pruebes.

Prueba a trabajar con submaestras para lineas de factura, pedidos, etc y si tienes algún problema en la práctica lo comentas y seguro que alguien te da la solución.

Esta estructura de la Base de Datos de Velneo, tiene ya 20 años , ha sido probada por miles de programadores procedentes de decenas de bases de datos y en general es el formato elegido. Por algo será y su prácticidad para este tipo de estructuras es optima. Qué es mas optimo que si tenemos que dar de alta lineas e inventar un id, que identifique univocamente a cada uno de esos registros este este compuesto de la cabecera y de un id propio autonúmerico, eso es una linea de detalle. Y eso nos lo gestiona la base de datos con solo definirlo.

En cuanto al tema que comentas de "lineas secuenciales", esa es otra cuestión. Pero que mejor si estamos obligados a tener una numeración secuencial de esas lineas, que estas se puedan renumerar como queramos, sin afectar a la base de datos. Declaras un campo Linea, Apunte, Asiento o lo que quieras y lo numeras a tu gusto, la base de datos no se vera afectada por tus posibles errores. A fin de cuentas ese numero de linea es un atributo, que en alguna ocasion, no en todas pues muchas veces ni se tiene que visualizar para nada, te puede ser exigido en alguna gestión, pero es un artibuto más, no tiene por que afectar a la estructura interna y muchas veces trasnparente al usuario de como unas tablas se ligan con otras.

Esto tiene cierta similitud, con el caso de los id, del campo artículos. El Id es algo interno, que puede ser autonumerico y que gracias a el e internamente todos los registros que enlazan con el articulo en cuestión, usarán y contendrán internamente.

Pero no tiene nada que ver con que el usuario, necesite un indice compuesto o una referencia compuesta por el proveedor, el material, y la longitud. El Id es una cosa y los indices y campos que queramos que el usuario final maneje son otra.

Aunque para gustos colores, pero primero experimentemos y dominemos ambas posibilidades antes de comparar.

Por ota parte es cierto que en las primeras versiones de V7 existió algún bug que pudo crear cierta confusión, pero el modelo es óptimo y como ya he comentado no es de V7, tiene 20 años y muchas, muchas instalaciones a sus espaladas.


([N1] Pepeto) #12

@cjribera

Tengo que dar la razón a Miguel Perez, en cuanto a la utilidad de las tablas submaestras.

Que en mi primera respuesta, dijera que no era mi estructura ideal, es cierto, no lo es, uso muy pocas tablas submaestras, pero cuando las uso, soy consciente de su utilidad y del servicio que prestan. Además, no creo que el análisis planteado por Juan (Catarso) sea el apropiado para el uso de este tipo de tablas.

Ademas, cuando creo una estructura de datos, no lo hago pensando en un futuro cambio de herramienta y que dicha estructura me sea valida para ese improvable futuro. ¿Hago una estructura pensando en otra herramienta que no es la que voy a usar?, ¡NO!, analizo la aplicación pensando en la herramienta que tengo entre manos, y lo hago intentando conseguir una solución robusta y sólida.

Además, en el hipotetico caso de tener la necesidad de cambiar a otra base de datos, me seria tan sencillo como añadir un campo numérico y un pequeño proceso para renumerar los registros y consegir asi un #ID secuencial y único para utilizar en el nuevo diseño.

Lo dicho, que no, que no las uso más a menudo, porque no veo la necesidad de usar una clave compuesta por 2 campos, cuando puedo resolver el mismo esquema con 1 campo, pero si las necesito, claro que las uso donde haga falta.

un saludo
José Luis
http://www.ascsl.com


([N4] mittosoftware) #13

@Pepeto, Cuando dices "Ademas, cuando creo una estructura de datos, no lo hago pensando en un futuro cambio de herramienta y que dicha estructura me sea valida para ese improvable futuro."
.
Al menos en mi caso, recuerdo cuando era estudiante de ingeniería, siempre insistían que al diseñar, debes hacerlo para la 'peor hipótesis'. En este caso, el principio te diría que, por muy a gusto que estés con tu herramienta, es lo mejor que tu diseño sea lo mas portable y estándar posible.
.
De hecho, apegarte a los estándares te previene muchos dolores de cabeza en etapas posteriores de desarrollo (ser estricto en la normalización y evitar los 'atajos' por ejemplo).
.
@Miguel, primero, lo de la gestión de líneas entonces no me quedo claro a que se refería, como siempre es autonumérico, yo creí que se refería a lograr la secuencia del número de línea, si no es eso, no me quedó claro de que gestión se hablaba.
.
Pero mas importante que eso, ya que tocas el tema de la Base de Datos Velneo y cuan avanzada es, yo quedé con consultas pendientes en cuanto a la BBDD en si, que al final no me respondieron. Lo pregunté porque es algo que he necesitado antes con otras BBDD y que seguro necesitaré a futuro en las BBDD que implemente con Velneo.
.
Me asaltó la duda viendo este hilo en el foro. http://velneo.es/foros/topic/particionado-de-tablas
Entonces, añado mas info sobre particionado:
http://www.dosideas.com/noticias/base-de-datos/576-incrementar-rendimiento-de-bbdd-con-qparticionado-de-tablasq.html
http://www.postgresql.org/docs/current/static/ddl-partitioning.html
.
Otro asunto importante, replicación y sincronización: http://www.postgresql.org/docs/9.1/static/high-availability.html

.
Son características necesarias de un gestor de base de datos, puse BD open source como ejemplo. ¿Estas capacidades, las tiene la BD Velneo?