CMS modules by everest poker.

Nombres de objetos, campos y controles

Imprimir
Valoración del Usuario:  / 8
MaloBueno 
Categoría: Teórico-práctico
Escrito por Neckkito

 

Si queréis bajaros este artículo en pdf pulsad aquí


NombresObjetosÍNDICE DE CONTENIDOS

*** INTRODUCCIÓN

 *** NOMBRES DE OBJETOS

*** NOMBRES DE CAMPOS

*** NOMBRES DE CONTROLES

*** PARA FINALIZAR ESTE ARTÍCULO

 

INTRODUCCIÓN

Este artículo nace debido a que, en estos años de ver bases y bases de usuarios, he podido comprobar que la utilización de nombres en objetos, campos y controles es algo que “usuarios inexpertos” descuidan. Descuidan por desconocimiento, básicamente. Es decir, que ese “descuidan” no lo digo con ninguna implicación negativa.

 

Partamos del punto en que debéis entender que todo lo que propondré en este artículo es, simplemente, eso, una proposición. Que nadie lo entienda como una “verdad absoluta”, dado que un simple vistazo en Internet nos permitirá descubrir diferentes maneras de hacer las cosas, todas ellas perfectamente válidas. Os ruego que tengáis esto en mente mientras leáis este artículo (si sois capaces de llegar al final... je, je...).

 

El principal problema, desde mi punto de vista, es la “estrechez de horizontes” a la hora de crear una base de datos. Me explico a través de un ejemplo:

 

Un usuario sin conocimientos de Access decide hacer una inmersión en esta aplicación y crea una base de datos simple. “La base de datos tiene que ser lo más clara posible”, piensa (y con razón). Y es cuando crea unas tablas así:

 

TABLA CON INFORMACIÓN CLIENTES

TABLA PARA DAR DE ALTA PRODUCTOS

 

Y, por extensión, la cosa funciona perfecta y crea los demás objetos de Access siguiendo la misma mecánica:

 

CONSULTA QUE FILTRA CLIENTES POR PROVINCIA

INFORME DE PRODUCTOS QUE ESTÁN DE ALTA

 

En la primera tabla, por ejemplo, crea, entre otros, los siguientes campos.

 

[Nombre del cliente]

[Domicilio del cliente]

[Domicilio de verano del cliente]

[Número de DNI del cliente]

 

Y sobre esta tabla crea un formulario llamado FORMULARIO CON INFORMACIÓN DE CLIENTES, donde le aparecen los anteriores campos, y, además, descubre los controles y empieza a añadir cuadros combinados, cuadros de lista, botones de comando...

 

La base de datos funciona a la perfección., con lo que las necesidades están perfectamente cubiertas.

 

Pasan unos meses (por ser optimista) y nuestro usuario aprende algunas funciones de Access, aprende algunos rudimentos de VBA y, por seguir siendo optimista, aprende algo de SQL. ¡Fantástico!

 

Entonces la pregunta es: ¿qué es lo que va a pasar?

 

NOMBRES DE OBJETOS

 

Los nombres de objetos deberían ser nombres cortos y lo más descriptivos posible. No habría que utilizar acentos en dichos nombres (insisto, por última vez, en que todo lo que diré son recomendaciones).

 

Quien conozca alguno de mis ejemplos verá que yo antepongo la letra:

 

T: Tabla

 

C: Consulta

 

F: Formulario

 

R: Informe

 

Es decir, que yo escribiría como nombre de tabla:

 

TClientes (o, abreviado aún más, TCli)

 

o, si fuera necesario por los motivos que sean,

 

TClientesAlta

 

De esta manera, si yo os digo que he escrito RInventario no necesito deciros que me estoy refiriendo a un informe.

 

Hay otros sistemas, como anteponer los siguientes prefijos para designar los objetos:

 

tbl: Tabla

 

qry: Consulta

 

frm: Formulario

 

rpt: Informe

 

Volviendo a nuestro estimado usuario de Access, supongamos que quiere crear un código VBA para manipular un subformulario en un formulario. Entonces debería escribir:

 

Forms![FORMULARIO CON INFORMACIÓN DE CLIENTES].[SUBFORMULARIO CON INFORMACIÓN DE ACTIVIDADES DE CLIENTES].Form.[Cuadro Combinado 234].Visible=False

 

Y si lo anterior se repite muchas veces en el código pues... para “tirarse de los pelos”.

 

Si yo escribo lo siguiente:

 

Forms!FCli.subFrmActCli.Form.cboAct.visible=False

 

¿No creéis que resulta un poco más eficiente?

 

Otro problema que podría aparecer sería cuando, al ejecutar el código, nos salta un error diciendo que no se encuentra el subformulario. ¡Pero si está ahí! ¡Lo estoy viendo! Y después de un buen rato de mirar y mirar nos percatamos que el nombre real del subformulario es [SUBFORMULARIO CON INFORMACION DE ACTIVIDADES DE CLIENTES]. ¿No es el mismo? Pues no, porque escribimos INFORMACION sin acento gráfico (¡anda, se nos olvidó ese acento!).

 

Si “sabemos” que a los nombres de objetos NUNCA les ponemos acentos, ese problemilla que nos ha consumido diez minutos (por ser de nuevo optimista) de búsqueda del error... “¡plof: desapareció!”

Alguno pensará: “Pero cuando se carga el formulario queda muy 'feo' que el usuario vea esa especie de criptograma 'FCliAct', ¿no?”.

Pues la verdad es que sí. Pero eso tiene una solución muy sencilla: si sacamos las propiedades del formulario y nos vamos a la pestaña Formato, a la propiedad “Título”, ahí podemos escribir el nombre que queramos. Una vez escrito, y cuando abramos nuestro formulario, veremos que su título es el que hemos indicado en esa propiedad.

 

NOMBRES DE CAMPOS

 

Lo explicado para los nombres de objetos en el punto anterior, en cuanto a la extensión de los mismos, es perfectamente aplicable a los nombres de campos.

 

Imaginaos que nuestro querido usuario aprende a utilizar una SQL de inserción de datos. Para programar la ejecución de una sentencia SQL de este tipo debería escribir:

 

miSql=”INSERT INTO [TABLA CON INFORMACIÓN CLIENTES] ([Nombre del cliente], [Domicilio del cliente], [Número de DNI del cliente]) VALUES (‘Pepito Pérez’, ‘C/ de la Zarzamora, 23’, “123456789Z’)”

 

¡Y eso que sólo he utilizado tres campos!

 

Si se hubieran escrito los nombres reducidos la SQL podría haber quedado así:

 

miSql=”INSERT INTO TInfCli (NomCli, DirCli, IdCli) VALUES (‘Pepito Pérez’, ‘C/ de la Zarzamora, 23’, “123456789Z’)”

 

Ventajas:

 

  • Reducción del tamaño de la SQL y mejora de su legibilidad

  • Si no ponemos espacios en los nombres no es necesario la utilización de corchetes (= escribimos menos)

 

En definitiva, ponemos los nombres de campos reducidos y sin espacio entre palabras

 

Nombre del cliente --- NomCli

 

Algunas veces nos podemos encontrar con tablas diferentes que utilizan nombres de campos que son muy parecidos. Lógicamente, podríamos escribir:

 

IdCli

 

en todas esas tablas para el campo que recoja el identificador del cliente. Ahora bien, eso podría causar confusión tanto en el código VBA (y SQL) como, por ejemplo, si necesitamos fijar el campo de relación entre un formulario principal y un subformulario.

 

La solución a este problema puede pasar por añadir algún tipo de identificador relacionado con la tabla. Por ejemplo, si yo escribo como nombres de campos:

 

IdCliNac

 

IdCliExt

 

no os costaría nada en absoluto identificar a qué tabla pertenecen si yo os digo que mis tablas se llaman:

 

TCliNacionales

 

TCliExtranjeros

 

Prosigamos. Nuestro querido usuario ha escrito los siguientes nombres de campos:

 

[% Desviación sobre ventas]

 

[Suma envases & productos]

 

A continuación vuelve a escribir un código VBA y... ¡sorpresa! Saltan errores por todas partes. ¿Qué es lo que está pasando?

 

Pues que está utilizando caracteres reservados de VBA en los nombres de campos. Y el código, al intentar leer los nombres de campos, interpreta el tanto por ciento (%) y el ampersand (&) como partes de código y no como nombre de campo.

 

Moraleja: no podemos utilizar caracteres reservados en los nombres de campos. ¿Y cuáles son esos caracteres reservados? Pues son los siguientes:

 

Nombre del carácter Carácter
Barra /
Interrogación final ?
Exclamación final !
Asterisco *
Guión -
Comilla simple '
Comilla doble "
Punto y coma ;
Dos puntos :
Símbolo del dólar $
Almohadilla #
Ampersand &
Porcentaje %

 

Nota: aprovecho la ocasión para comentaros, como curiosidad, que si en alguna ocasión, con vuestro código VBA, tenéis problemas con algún carácter en los valores de los campos (ojo, en los valores de los campos, no en los nombres), podéis solucionar ese problema utilizando variables temporales. Os recomiendo este excelente artículo de Chea aquí o, si os lo queréis bajar en pdf, aquí.

 

De nuevo nuestro usuario nos dirá ahora: “Pero si yo hago un formulario basado en una tabla los nombres de los campos quedan muy “feos”. Efectivamente, un nombre de campo llamado “PorcVtasCli” queda muy poco elegante de cara a un usuario de la base de datos. Pero, ¡tranquilos! No hace falta “matarse” cambiando etiquetas de campos.

 

¿Por qué? Porque cuando estamos creando el campo en la tabla, en la parte inferior donde están las propiedades del campo, tenemos una propiedad llamada “Título”.

 

Si en esa propiedad escribimos el nombre que queremos que vea el usuario, a la hora de crear el formulario sobre la tabla, Access “buscará” primero si hay algún valor en esa propiedad y si lo encuentra pues lo utiliza como nombre de etiqueta. ¡Y listos!

 

NOMBRES DE CONTROLES

 

Finalmente, todo lo dicho en los puntos anteriores es de perfecta aplicación aquí. Si insertamos un cuadro combinado en un formulario podemos observar que Access nos escribe como nombre predeterminado “Cuadro CombinadoXX”, donde XX es un número.

 

Manejar esa nomenclatura es farragoso en VBA, principalmente pos dos motivos:

 

  • El que ya os he comentado de “pesadez” de escritura

  • El problema que nos aparece para identificar el control si el código nos marca un error.

 

Imaginaos que nuestro usuario tiene un código en un módulo asociado a un formulario así:

 

 

Private Sub Cuadro_Combinado23_Click()

 

‘Código

 

End Sub

 

Private Sub Cuadro_Combinado37_Click()

 

‘Código

 

End Sub

 

Private Sub Cuadro_Combinado78_Click()

 

‘Código

 

End Sub

 

Private Sub Cuadro_Combinado97_Click()

 

‘Código

 

End Sub

 

 

Y, lo anterior, con siete cuadros combinados más.

 

Salta el error en el “Cuadro_Combinado37". ¿A cuál de los diez cuadros combinados se está refiriendo?

 

Tendríamos que irnos al formulario en vista diseño, localizar cuál es el cuadro combinado 37, y arreglarlo. Os aseguro que como tengamos muchos errores de código eso es muy “time consuming”.

 

Y ahora multiplicad ese problema por 15 formularios... je, je...

 

Existe una nomenclatura para los controles. Os pongo a continuación la correspondiente a los controles más comunes:

 

Nombre control Prefijo
Cuadro de texto txt
Etiqueta lbl
Cuadro combinado cbo
Cuadro de lista lst
Casilla de verificación chk
Botón de opción

opt

Marco de opciones mrc
Botón de comando cmd
Objeto OLE ole

 

Es decir, que si yo creo un cuadro combinado para recoger información sobre el campo [% Desviación Aplicado] lo que haría sería:

 

  • Uno: cambiar el nombre de ese campo a, por ejemplo y simplemente, “PorcDesviacion” (ojo, ¡sin acento!).

  • Dos: llamar, por ejemplo, a mi cuadro combinado cboPorcDesv.

 

Y, si me permitís, os haré un pequeño comentario personal respecto a una letra española: la eñe. 

Yo no utilizo esta letra en ninguna parte de Access. “¿Por qué?”, me preguntaréis. Pues básicamente por dos motivos:

  • Primero, porque si, por los motivos que sean, utilizamos un teclado no español vamos a encontrarnos con que no tenemos esa letra.
  • Segundo, porque si pedimos ayuda a algún amigo no español (lo que implica, en el fondo, que no va a tener un teclado español) se va a “tirar de los pelos” cuando tenga que “lidiar” con esa “letrita”... je, je...

 

PARA FINALIZAR ESTE ARTÍCULO

Bueno. Lo anterior ha sido una “pincelada” sobre el tema de los nombres. Deciros que existe una página con propuestas sobre normalización según el sistema Leszynski de nombres que podéis consultar aquí (o bajar en pdf aquí). Os lo pongo porque hay muchos programadores que siguen este sistema.

De una manera u otra, y utilicéis el sistema que utilicéis, lo que debemos tener en cuenta, desde mi humilde punto de vista, es que todo resulte lo más cómodo posible para nosotros como administradores-programadores de la base de datos.

Un saludo, y...

¡suerte!

 

 

Saturday the 19th. Joomla 2.5 Templates. Neckkito's baby 2012 --- Hosted by: www.siliconproject.com.ar
Copyright 2012

©