A ver que os parece

[[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 Noteví]

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