A ver que os parece

[[José Luis Garcí]]

Propongo a los compañeros la siguiente idea, por que no creamos, una serie de temas relacionados con tablas especificas, en que pongamos el nombre del campo, tipo, tamaño y una pequeña descripción y o aclaración, por ejemplo empezar con un tema llamado Estructura clientes, que ira como no sobre la tabla clientes y pondríamos más o menos (es una idea)

CodCli, AlfaNumeric, 20 , Guarda el código del cliente, alfanumérico, para que admita letras y números
Nomcliente, Alfanumeric, 40, nombre del cliente
Etc...

Como veis puse alfanumeric, puede ponerse String, etc.. no importa en este caso el tipo de base de datos y nos ayudaría a mejorar nuestras bases de datos, actuales y en un futuro, enseñarnos nuevas posisbilidades etc, tambien podrimaos poner indices y campos con autogeneradores, etc..

[[newtron]]

Amigo José Luis.

Si bien es cierto que en las tablas de clientes, artículos, proveedores, etc. hay campos que hay que tener como mínimo como son en el caso de clientes el código, nombre, dirección, etc. Aparte de esto los demás campos están bastante relacionados con el funcionamiento y las opciones de la aplicación en particular. Me explico, si tu aplicación gestiona nóminas te hará falta el número de inscripción de la seguridad social de la persona, cosa que en un programa de gestión normal y corriente no tiene mucho sentido.

De una forma de otra si a ti o a alguien del foro le interesa yo no tengo ningún problema en publicar aqui un fichero ini de mi aplicación de gestión en la que se almacena la descripción de todas las tablas y campos que usa (que son bastantes).

Saludos

[[José Luis Garcí]]

gracias por tu opinión newtron, pero creo que no has entendido lo que quería expresar, me encuentro a menudo con gente que tiene muchos conocimientos de programación de webs, apis, gráficos, juegos, y gestión, pero que en cuanto les sacas de su campo se pierden, no importa ni el lenguaje usado ni el tipo de DB que usemos, el problema es el mismo, se pierden y el comentario es igual, debería haber hecho este campo así, me falto esto, tengo que modificar el ancho, etc.

La idea que propongo es hacer una especie de guía de bases de datos de gestión y por que usar un campo o otro, te pongo un ejemplo, yo programo bases de datos para mi programa sobre la fabricación de productos de limpieza, a parte de usar tablas y campos muy específicos para este sector, nos encontramos con el caso de un producto de limpieza debe llevar caducidad, la res puesta es sí, ya que si un producto es extremadamente ácido o alcalino, no proliferan germenes degrada-torios, pero en cambio en productos controlados si.

otro ejemplo de lo que digo, es que tamaño y de que tipo debería ser el campo Código Postal, numérico, alfanumérico, de 5, 6 10, etc..

Como digo se trata de tener una visión general de lo que debería ser los campos de las tablas, ya cada uno decidirá si usa unos o desecha otros y como muy bien dices, para cada aplicación podemos tener tablas muy especificas, con campos específicos.

[Casimiro Notevi]

Aunque eso también variará dependiendo de la zona/región/país, por ejemplo, el código postal o el teléfono no será igual en España, Perú o USA... supongo.

[[oscarac]]

me parece una buena idea...
siempre y cuando consideremos cuestiones inherentes a nuestra region o zona

[[José Luis Garcí]]

Pienso mejor en hacer un tipo estándar, porque podemos encontrarnos en un país y tener que mandar cartas, documentos etc a otros, pensar si el más largo de todos tiene 10 de ancho, no e mejor dejarlo a diez, que tener uno de 5 para España y de repente un cliente a mandar mercancía en XXXX y allí su equivalente tiene 10 de tamaño o cualquier otro campo. Por poner otro ejemplo yo vivo en Gran Canaria, que pertenece a España, por todo el país el impuesto es el IVA, exceptuando en mis islas que es el IGIC, la mayoría de los programas de la península suelen venir con el campo IVA, mientras que los programadores que conozco en la isla solemos usar un campo en la configuración que llamamos impuestos y donde ponemos el nombre de este, de esta manera sirve para las islas Canarias, para la península y para cualquier país, pero claro sólo en el impuesto, que pasara, con otros muchos campos???

[[newtron]]

El tema es que la configuración del campo dependerá muy mucho de la aplicación y el sector al que esté dirigida. En el ejemplo de los códigos postales ciertamente cambiarán en los distintos paises y lo suyo es que tuvieran una longitud suficiente para cubrir todas las posibilidades pero en mi caso en particular la gran mayoría de mis clientes usan códigos postales nacionales y ¿qué hago? ponerselo limitado a 5 dígitos y con una consulta de los mismos para que no se equivoquen. Si lo pusiera a 10 dígitos por si tuvieran (caso improblable) que necesitarlo me chillarían porque se equivocarían en la longitud del mismo y me dirían que se lo pusiera a 5 que es lo que usan.

El tema es peliagudo en ese sentido.

Saludos

[[José Luis Garcí]]

hola newtron, tienes toda la razón, no te discuto que la tengas, pero ahí es donde tenemos que entrar nosotros, debemos controlar esa situación, como, pues es una manera fácil si el país es España, limitamos la entrada dentro del onchange de su respectivo edit no permitiendo mas de 5 o 6 caracteres (si incluyes el punto o no) y en el onkeypress controlando si es un numero o el punto. Aprovecho y te lo planteo de la manera contraría, que diría el cliente si tuviese que mandar correspondencia a otro país con un alfanumérico de 10 dígitos, quien tendría que modificarlo a posteriorí, intenta verlo de eta manera

[[newtron]]

Cierto, si se diera esa circunstancia tendría un problema. Por ese motivo mi programa está preparado para hacer modificaciones particulares de los campos sin tocar el código del programa y mediante ficheros ini. Me explico. Siempre que llamo a un formulario en el formcreate se lee un fichero de texto asociado a ese formulario y en el que se pueden modificar las propiedades del campo, el tamaño, color, longitud, tipo (cadena, entero, fecha...), etc. De esta manera consigo que el cliente tenga una versión personalizada del programa sin que le afecten nuevas actualizaciones del ejecutable. Puedo cambiar las propiedades de los campos, eliminarlos, insertar nuevos, etc. en definitiva, crear una pantalla totalmente a medida sin tocar una linea de código. Igual esta idea le puede venir bien a alguien para sus programas.

Saludos

[Casimiro Notevi]

¿Y eso cómo lo solucionas en la BD?, quiero decir qué si hacen falta más campos o cambiarles el tipo, etc. ¿creas la BD una vez definidos los campos en el .ini?

[[José Luis Garcí]]

Sería bueno que nos pusieses un ejemplo, pues se ve muy interesante newtron.

[[newtron]]

Os cuento.

Toda la estructura de la base de datos de mis aplicaciones está en un fichero llamado DBGes.ini, que contiene algo parecido a esto...

[Tablas]
Tabla1=Clientes
Tabla2=Proveedores -------> Relación de todas las tablas
Tabla3=Articulos

[Clientes]
Campo1=CODIGO,C,6,0
Campo2=NOMBRE,C,40,0
Campo3=TOTALCOMP,N,12,2 ----> Descripción de cada una de ellas
Campo4=FECHAUC,D, (Nombre del campo,Tipo,Longitud,Decimales)
Campo5=OBSERVA,B,
..etc

Indice1=CODIGO,CODIGO,"" ----> Indices para esta tabla
Indice2=NOMBRE,NOMBRE,"" (Nombre del índice,campo (si es único),Campos(si son más de uno)

[Proveedores]
Campo1=CODIGO,C,6,0
Campo2=NOMBRE,C,40,0
..etc

Indice1=CODIGO,CODIGO,""
Indice2=NOMBRE,NOMBRE,""

[Articulos]
Campo1=CODIGO,C,20,0
Campo2=DESCRIPCIO,C,40,0
Campo3=PVP,N,12,4
..etc

Indice1=CODIGO,CODIGO,""
Indice2=DESCRIPCIO,DESCRIPCIO,""

De esta manera relaciono todas las tablas y sus campos. En mi programa hay una opción para regenerar las tablas y actualizarlas en función de los campos de este archivo. Este archivo es común para todas las instalaciones.

Al mismo tiempo hay otro fichero que se llama DBGesLocal.ini en el cuál meto las personalizaciones de cada cliente si las hay. La estructura es la misma que el del general, si un campo de una tabla se repite en el DBGesLocal.ini se usan las especificaciones de este último y si no existe se agrega a los del fichero general. De esta manera cuando actualizo el programa solo actualizo el DBGes.ini pero el DBGesLocal.ini no lo toco con lo cuál se mantienen los cambios específicos para ese cliente.

Por otro lado tengo un montón de componentes propios como son uno para formularios con todas las opciones ya predefinidas de adelante, atrás, final, crear, etc. y dentro de ese formulario inserto componentes propios para edits, combobox, grids, etc. asociados al mismo y que tienen todas las propiedades que necesito de tipo de campo, color, longitud, tabla, campo, etc. Cuando creo un formulario determinado lo primero que hace es leer el fichero txt asociado para ver si tiene que modificar o crear campos nuevos e igualmente esos ficheros txt pueden ser locales y no se tocan cuando se actualiza el programa. De esta manera puedo personalizar el 80% del programa sin tocar una sola linea de código.

Ejemplo de un fichero txt para el fichero de almacenes:

[Formulario]
FuenteNombre=MS Sans Serif
FuenteTamano=8
FuenteColor=-2147483640
Titulo = Fichero de Almacenes
Ancho=399
Alto=137
Color=-2147483633
Tabla=Almacenes
Indice=CODIGO
Impreso=ListadoAlmacenes.txt

[Elemento1]
Control=TNTEdit
Nombre=TxtCodigo
Texto=TxtCodigo
Color=11777023
Alineacion=Izquierda
LocalTabla=Almacenes
LocalCampo=CODIGO
VisibleConsulta=Si
VisibleEdicion=Si
VisibleInsercion=Si
ActivoConsulta=Si
ActivoEdicion=No
ActivoInsercion=No
Y=38
X=86
AY=21
AX=24
FuenteNegrita=Si
FuenteItalica=No
FuenteSubrayada=No
FuenteTachada=No
Ajuste=Si
Puntacion=No
Decimales=0
Longitud=2
Tipo=Entero
INTEGRIDADTabla=ALMACENES
INTEGRIDADCampo=CODIGO
INTEGRIDADIndice=CODIGO
INTEGRIDADValor=CODIGO
EventoCambio=No
Indice=No


No sé si habreis entendido algo de todo este rollo pero si quereis os puedo dejar una copia del programa para que veais un poco como está orientado.

Saludos

[[José Luis Garcí]]

a mi personalmente me gustaría ver lo que dices con una pequeña demo de ejemplo bastaría, gracias newtron

[[newtron]]

Ningún problema. ¿Quieres ver un ejecutable funcionando con los ficheros de los que te hablo? porque para poder ver los fuentes tendrías que instalarte mis componentes y los componentes de la base de datos que uso que a vosotros seguro que ni os suena.

Saludos

[[José Luis Garcí]]

Si no tienes problema, sería perfecto, todo lo que sea aprender siempre es bueno.

[[newtron]]

Empezado por José Luis Garcí

Si no tienes problema, sería perfecto, todo lo que sea aprender siempre es bueno.

Vale, pero ¿qué quieres entonces, el ejecutable o los fuentes con los componentes?

[[fjcg02]]

Hola,
estoy interesado en este tipo de soluciones.
Estoy trabajando para hacer un framework que permita hacer básicamente lo que propone newtron pero que la información resida en la propia BBDD.

Tengo algo hecho, y en principio coincido en lo que propone.

Por cada tabla o vista
Relación de campos con nombre, etiqueta, longitud, máscara de edición, si es foreign key tabla relacionada y campos que actualiza, función de validación , si es una lista de valores qué lista es ( se guarda en otra tabla) ... y lo que se nos ocurra.

Por cada formulario ( esto tengo pendiente de desarrollar )
Entidad principal ( tabla o vista ), isposición de los campos ( en cuatro columnas o más ), pestañas de tablas detalle, ....

La idea es la misma, quiero hacer una aplicación generadora de aplicaciones, ese es mi sueño.

Lo más difícil ( o eso creo ) es cómo incluir las reglas de negocio en este 'puzzle' de manera que sean sencillas de mantener.

Si juntamos esta técnica con la herencia, en principio creo que podemos hacer el 100% de las aplicaciones de gestión con un esfuerzo bastante pequeño.

Alguna vez he querido meterme con ORM's tipo tipof y esas vainas, pero me resultan muy complicados para lo que yo demando.

Ahora no puedo incluir información, pero esta noche publico lo que tengo adelantado para que le echeis un vistazo.

Un saludo

[[José Luis Garcí]]

lo ideal es una pequeña base de datos con un 4 o 5 campos, así con una pequeña aplicación seria los fuentes, componenetes(si son libres) y el ejecutable por si hay problemas de version de delphi, o tuviese que adptarlo para mi versión (delphi 2010), de todas maneras, si puedes decirnos que componentes y tipo de BD. Muchas Gracias.

[[newtron]]

Los componentes son hechos por nosotros (bueno, por uno que había en la empresa que si que sabía programar ), no son libres pero no tengo inconveniente en pasártelos si te sirven de ayuda. Todo está desarrollado con delphi 2007 por lo que no creo que tengas problemas en hacerlos funcionar.

La base de datos se llama elevateDB y puedes descargar los componentes en www.elevatesoft.com, te harán falta para poder ejecutar el proyecto así que puedes ir instalándola mientras te preparo un proyecto de ejemplo.

Enviame un mensaje privado con tu correo y te enviaré un ejemplo para que veas como funciona todo.

Saludos