Nomenclatura y estandares

[Mauro.NET]

Hola que tal, aca veo mucha gente experimentada, y me gustaria saber si ustedes tienen definida su propia nomenclatura estandard para el nombre de las tablas y campos en bases de datos, de manera tal que un programador se desempeñe eficientemente al crear, mantener y entender consultas SQL complejas, y asi evitar confusiones y posibles ambiguedades que retrasan su labor.

Yo actualmente en la empresa donde estoy tienen 150 tablas y usan un estandard en la nomenclatura que me incomoda un poco al programar consultas sql, ya que a cada rato tengo que usar el guión bajo, y ademas ese sufijo numerico es dificil de recordar.

Ejemplo:

Departamentos_003
Codigo_003
Descripcion_003

Empleados_004
Codigo_004
Codigo_003
Nombre_004
Direccion_004
Telefono_004

Entonces la apariencia de la consulta SQL es algo asi:

SELECT E.*, D.Descripcion_003
FROM Empleados_004 E INNER JOIN Departamentos_003 D
ON E.Codigo_003 = D.Codigo_003

En consultas complejas esto se torna complicado y necesito algo mas amigable, asi que los invito a aportar sus ideas..... y quien dice que el Club Delphi termine definiendo estandares en la programacion :)

[Pablo Carlos]

Hola... no se si existen estandares pero lo que yo uso es las tres primeras letras hacen referencia a la base y luego el campo el cual si es de dos nombres lo achico a sus primeras letras separadas por un guion bajo por ejem:

Select EMP_Num_Doc // numero documento
From Empleados.db, Persona.db
Where EMP_Empleados_id = PER_Persona_id

Este es el formato que uso y quizas no sea el mejor pero me resulta facil a la escritura y lectura.-
Este es mi aporte y no es mala idea el de crear un nomenclador estandar de manera que si tenemos que arreglar y/o modificar otra aplicación (no nuestra) nos sea más fácil sin perder tiempo en tratar de entenderla.-
Saludos

[Al González]

¡Hola a todos!

Este tema me interesa porque soy un partidario de la estandarización de nomenclaturas. Personalmente he comprobado cómo el llevar un estándar reduce significativamente los tiempos de desarrollo, depuración, mantenimiento y modificación del software.

En lo referente a bases de datos, de entrada les comento que no uso el guión bajo ("_") en el nombre de sus elementos. No lo utilizo para los nombres de tablas, campos y otros objetos por tres razones:

1. Es difícil de teclear. Esa fracción de segundo que dedicamos a sostener el Shift mientras presionamos (y recordamos su posición según la configuración de teclado) el guión bajo termina siendo un detalle incómodo para el programador. Y todos sabemos que en desarrollo de software entre menos detalles incómodos tengamos mejor y más rápido salen las cosas. Somos muy dados a optimizar la memoria y tiempo consumidos por las rutinas de código, pues lo mismo debemos aplicar a las rutinas laborales ¿no creen? ;).

2. Es poco estético y muchas veces innecesario. Cuando se permite el uso de mayúsculas y minúsculas (y no hay conflictos técnicos importantes al respecto), se puede prescindir del guión bajo empleando altas y bajas a la manera de NomenclaturasBuenas, PrecioMenudeo, PrecioMayoreo.

3. Se hace invisible en hipervínculos y textos subrayados. Si por ejemplo, en la documentación de la base de datos tenemos una sección o hipervínculo con el título subrayado "DEPENDENCIAS DE LA TABLA AREAS_VIGENTES" ("DEPENDENCIAS DE LA TABLA AREAS_VIGENTES"), un programador de nuevo ingreso podría pensar que se trata de las dependencias vigentes de la tabla AREAS en lugar de las dependencias de la tabla AREAS_VIGENTES. Ese tipo de confusiones entorpecen el trabajo de los desarrolladores.

Por otra parte, creo cada tabla con un nombre en plural cuando ésta podrá contener más de un registro, como sucede casi siempre (por ejemplo, EMPLEADOS, AREASVIGENTES), y en singular solamente cuando es una tabla de un sólo registro (por ejemplo, CONFIGURACION, DATOSEMPRESA).

Con respecto al campo de llave primaria o de identidad, éste lo nombro simplemente "ID" (el uso del término ID es ya un estándar fuertemente aplicado y aceptado por la comunidad mundial de desarrolladores), y para los campos que se relacionan con el ID de otra tabla utilizo el nombre completo de esa otra tabla con el prefijo "ID". Por ejemplo, si tenemos dos tablas, "VENTAS" Y "VENTASPARTIDAS", en una relación maestro-detalle, respectivamente. Los campos llave de dichas tablas son:

VENTAS.ID (identificador de registro, llave primaria)
VENTASPARTIDAS.ID (identificador de registro, llave primaria)
VENTASPARTIDAS.IDVENTAS (relacionado con VENTAS.ID, llave externa).

Nótese también que el nombre de la tabla detalle, "VENTASPARTIDAS", lleva como prefijo el nombre de la tabla maestra ("VENTAS").

Hay quienes no utilizan nunca ID como nombre completo de campo, sino que siempre le anexan el nombre de una tabla ("VENTAS.IDVENTAS", por ejemplo). Encuentro tres desventajas en esa forma de hacerlo:

1. Si el nombre de la tabla cambiara, tendríamos que cambiar también el nombre del campo.

2. Es un pleonasmo. Como decir «cayó algo del cielo de arriba». ¡Cervantes se levantaría de su tumba! Ya sabemos que el cielo está arriba. En programación debe uno cuidar que no se caiga ni en la escasez ni en la abundancia de texto, ya que los dos extremos le exigen una mayor cantidad de tiempo-neurona al cerebro.

3. Se pierde la distinción entre los nombres de campos de llave primaria y los de llave externa/secundaria. Como lo propongo ("VENTAS.ID"), al comenzar a leer la sentencia SQL «Select IDVentas...» podemos intuir que se trata de una consulta sobre la tabla VENTASPARTIDAS antes de llegar al From. En cambio, si el campo fuera "VENTAS.IDVENTAS", forzosamente tendríamos que leer algo más de la sentencia Select para estar seguros de si es una consulta sobre la tabla VENTASPARTIDAS o sobre la tabla VENTAS.

Allende, hay quienes, para campos relacionados, utilizan el nombre de la otra tabla con el par de letras "ID" como sufijo en lugar de prefijo. Ejemplo: "VENTAS.CLIENTESID". El problema de ese estilo es que se pierde uniformidad y eficacia cuando listamos o buscamos los campos de una tabla por orden alfabético. Por ejemplo, quizá estamos tecleando instrucciones de la aplicación o SQL en un editor que soporta auto completado de código (code insight), y enseguida queremos escribir el nombre de un campo relacionado pero no recordamos como se llama la otra tabla. De la manera que lo propongo ("ID" como prefijo), sólo tenemos que teclear ID y estaremos a un paso de seleccionar el campo cuyo nombre completo no recordábamos. En cambio, si se utiliza ID como sufijo, tenemos que examinar la lista de campos completa para localizar el nombre que buscamos.

Este esquema de nomenclaturas que propongo y utilizo ha resultado de lo más eficiente e inteligible para los desarrolladores que trabajamos en diversos proyectos de mi empresa y de algunos clientes. La esencia del mismo es ser prácticos y sencillos, no complicarnos con nomenclaturas bárbaras sostenidas más en fundamentalismos sico-informáticos que en su facilidad de uso y resultados de la vida real.

Generalmente el programador común no acepta con facilidad cambiar de estilo (alguna vez yo fui uno de tantos obstinados, viviendo en mi pequeño y perfecto mundo). No obstante, la tolerancia y la flexibilidad son un signo de madurez muy valorado por las empresas, y dos cualidades imprescindibles para lograr lo que uno quiere en la vida.

Propongo mi esquema de nomenclaturas para bases de datos, como cimiento de un estándar al que podamos contribuir todos.

Espero esto sea de utilidad, seguimos en contacto.

Ahora si, a dormir se ha dicho. ¡Hasta mañana!

Al González. :)

[Mauro.NET]

En el caso de las tablas relacionadas que conforman un maestro detalle directo, como por ejemplo en el caso de FACTURAS, (cabecera e items),
a las tablas las llamo

Factura_021
Item_Factura_022

Lo del sufijo numerico y guión bajo reconozco que es pésimo. En una base de datos nos encontramos con muchas relaciones de este tipo, y hasta ahora lo unico que encuentro rapidamente en mi base son los Items por que estan todos agrupados por el prefijo "Item_", si este modelo fuera comodo para alguno, usaria el prefijo "Cab_" o algo asi para identificar perfectamente las cabeceras.

Pienso que hay que organizar las cosas como dice la teoria general de los sistemas: "De lo general a lo particular".

Entonces a estas tablas las llamaria

FacturaCab
FacturaItem

solo estoy tirando algunas ideas, pero la fruta está muy verde todavia...
espero que ustedes aporten algo a esta iniciativa.

[roman]

¡Caramba Al! Has escrito toda una novela :)

En mucho estoy de acuerdo contigo. Yo solía llamar mis llaves primarias anteponiendo el nombre de la tabla hasta que, como dices, me percaté del pleonasmo.

Creo que hay que observar que lo de llamar ID a la llave primaria es más que una convención de nomenclatura; es una convención de que todas las tablas tendrán una llave primaria formada por un sólo campo.

Para el resto de los campos pues trato de usar nombres que me digan algo. En una tabla de productos, descripcion me parece un nombre adecuado para la descripción del producto. Es decir, ¿para qué usar nombres raros?.

Para llaves foráneas, lamento no concordar con Al (eso de por si acaso usamos un editor que soporte autocompletado me parece una razón un poco artificial :p ).

La relación en mi tabla productos al cliente se llama cliente_id. Cuando hacemos joins:


productos.cliente_id = clientes.id


me parece muy natural que vayan en el mismo orden. No omito el guión bajo porque con la mano izquierda oprimo SHIFT y con la derecha el guión y me sorprende que Al, que sabe mecanografía, esté en contra de su uso :D

// Saludos

[ContraVeneno]

Saludos a todos

Vaya que Al se avento todo un cápítulo sobre nomenclaturas, pero en general, estoy totalmente de acuerdo con lo que dice. De igual forma estoy en contra del uso del guion, prefiero usar las mayúsculas y minúsculas como bien menciona Al en sus ejemplos. Supongo que leímos el mismo libro o algo similar porque utilizamos los mismos estándares. Saludos Al :D

Habría que mencionar, que cada programador tiene su propio estilo con respecto a las nomenclaturas y cada quien esta en su derecho de utilizar el método que más le guste. Pero cuando trabajas en grupo, el hecho de cada quien utilize su propio estilo se convierte en un problema; lo más conveniente es que el grupo defina sus políticas y estándares para facilitar el trabajo de todos y que los integrantes del grupo se ajusten a estos estándares y políticas.

Otro punto sería, el utilizar prefijos que sean muy claros para todos, de lo contrario sería mejor utilizar la palabra completa. De cualquier manera todos sabemos mecanografía y podemos escribir muuuy rápido :D :p (ya en serio, aprender mecanografía es muy sencillo y te trae muchos beneficios. Es altamente recomendable aprender mecanografía)


Saludos

P.D. Es la primera vez que veo que colocan prefijos o subfijos numéricos en una nomeclatura, no entiendo cual es la función de hacer esto y no veo ninguna razón para hacerlo. :confused:

[roman]

De igual forma estoy en contra del uso del guion, prefiero usar las mayúsculas y minúsculas como bien menciona Al en sus ejemplos.


¿Y por qué es más difícil oprimir SHIFT para el guión que para una mayúscula? :confused:

// Saludos

[ContraVeneno]

Nunca dije que fuera más dificil o más fácil. Y si, creo que es lo mismo utilizar el shift para poner una mayúscula que para poner el guíon (o subrayado).

Pero mi muy particular y muy personal punto de vista, sigue siendo el mismo: yo no utilizo el guión, me parece poco estético y siento que escribo un caracter extra (multiplicado por 10 campos y multiplicado por 100+ tablas, son demasiados caracteres extra); prefiero escribir "TirePosition" que escribir "tire_position".

Pero como dije antes, este es mi muy particular y muy pesonal estilo, cada quien es libre de utilizar el estilo que más le guste; cuando trabajas en grupo, el estilo lo definirá el lider del grupo o el grupo en conjunto.

--Saludos

[Al González]

¡Hola a todos!

Gracias por sus comentarios Román, Eärandir.

Casi no suelo hacer aclaraciones sobre algo que ya de por sí es claro, pero esta vez haré una excepción que considero prudente para la correcta fluidez del tema.


...No omito el guión bajo porque con la mano izquierda oprimo SHIFT y con la derecha el guión y me sorprende que Al, que sabe mecanografía, esté en contra de su uso :D...
En parte por ello escribí «difícil» en letra cursiva. Trato de ponerme en los zapatos de todos los programadores que integran un grupo de trabajo. Además expuse claramente otras dos razones por las cuales prefiero abstenerme de utilizar el guión bajo.


...Supongo que leímos el mismo libro o algo similar porque utilizamos los mismos estándares. Saludos Al :D...
Hombre, prefiero no decir cuántos libros de informática he leído (http://www.clubdelphi.com/foros/showthread.php?t=5604) :D. Quizá sea que un servidor también vivió en Torreón (http://www.clubdelphi.com/foros/showthread.php?t=11845) ;). Y ya de paso te pido una disculpa por lo que pensaba de tu ciudad hace ocho años (http://www.clubdelphi.com/foros/showthread.php?t=20887) :o.


Seguimos en contacto.

¡Un abrazo a todos!

Al González. :)

[Mauro.NET]

Hola chicos, me sorprende la repercusión que tuvo este hilo hacia ustedes, probablemente tuvieron la misma inquietud alguna vez. Gracias por sus aportes.

Con respecto a lo del uso del guion bajo, por experiencia personal, yo utilizo teclado ingles por comodidad, pero esta tecla no está al lado del shift, sino arriba de todo donde estan todos los teclas de caracteres especiales &^&*()_=-+ etc.
Pero la ventaja de este tipo de teclados es mucho mas relajado a la hora de programar en delphi, ya que no tengo tengo que presionar tantas veces la tecla shift para los simbolos comunes en delphi, como por ejemplo = ; ' [ ] / como otros teclados.

Con respecto a la lectura de codigo SQL, no deberiamos dejar de lado si las palabras reservadas del SQL es convenientes mostrarlas en mayusculas o en minusculas, yo normalmente opto por la primera opcion y trato de orgainizar el codigo para que quede amigable posible para el programador.

;)

[ContraVeneno]

Al, no te apures, al ciudad si ha cambiado en los últimos 8 años, supongo que te sorprendería... eso sí, la tierra y la falta de agua seguirán, no por nada es zona desértica y las tormentas de arena (polvo) seguirán y seguirán. :D

Continuando con el tema, creo que hay puntos que ya son de obligación para todos los programadores; sobre los cuales ya se han escrito muchos manuales, tips, etc:
1.- Palabras reservadas en SQL en mayúsculas (hay quien incluso utiliza este método para todas las palabras reservadas del lenguaje que utilizan)
2.- Indexación o sangría para que el código se lea mejor.
3.- (el más olvidado de todos y que podría resolver muchos problemas) Colocar comentarios en el código

Por cierto, sigo sin entender porque o para que colocar subfijos o prefijos numéricos en la nomenclatura :p

Saludos!

[roman]

Yo en cambio nunca he entendido porqué la insistencia en usar mayúsculas para las palabras reservadas... se ve taaan feo :(

¿O es que en algún momento podría pensar que 'select', 'join', 'delete' son nombres de campos? Quizá al comenzar a trabajar con sql se preste a confusión pero después es igual que en un escrito cualquiera que esté plagado de mayúsculas.

Eso sí, la indentación y apropiados cambios de línea ayudan mucho.

// Saludos

pd: a mí también me gustaría saber la necesidad de los prefijos, sufijo, mejifos numéricos.

[Mauro.NET]

En la empresa donde estoy usan sufijos numericos, (Nombre_del_Campo_123) y a medida que voy creando una nueva tabla, voy incrementando en uno. En fin, ese numero es el orden de creacion de tablas, que para mi gusto no me dice nada y no le encuentro ninguna utilidad. Pero si ya tenes una DB con ese estandard adoptado, seria muy costoso modificar integramente el sistema para adaptarlo a un nuevo estandard. Donde estoy yo, tenemos que seguir usando ese viejo estandard propio nos guste o no. Con el tiempo de das cuenta que al trabajar con cientos de tablas, se hace dicifil recordar, y ademas las consultas sql se tornan muy confusas para mi gusto, sobretodo cuando hay comparaciones de campos con valores numericos. En todo caso usaria sufijos con letras, pero gual no me cuadra la idea. por algo soy insistente por que definamos estandares comodos para la mayoria, aunque estoy de acuerdo con mucha de las propuestas, yo igualmente seguire investigando.

[Lepe]

Pues yo estoy en contra del "guión bajo" :D, como ya han dicho, me parece un caracter extra e incómodo, aún cuando sé mecanografía ;).

Solo añado una cosita más, para las llaves externa (Foreign Key) suelo usar FIDVENTAS, F de Foreign Key, sufijo ID, y por último la tabla.

Para un nuevo programador, le facilita la tarea de "deducir de donde viene", pero reconozco que algunas veces olvido la "F" y me harto de buscar el campo IDVENTAS, ¿quizás cuando más espeso está uno? ;)

Un saludo

[ContraVeneno]

Estuve reflexionando un poco sobre el tema del uso de las mayúsculas para las palabras reservadas y creo que Roman tiene razón. La verdad es que si se vuelve un poco molesto estar escribiendo las palabras reservadas en mayúsculas y más ahora que el mismo lenguaje las resalta o las pone en otro color, incluso aquí en el foro tienes la posibilidad de colocar etiquetas y tambien las marca.

Saludos :cool:

[Mauro.NET]

Otra cosa que se me estaba escapando, es acerca de los alias que uno suele ponerle a una tabla en la consulta SQL. Ustedes estan de acuerdo con su uso? Pues yo con el tiempo me di cuenta que me resultan incomodos sobretodo en consultas complejas, debido a que aveces llegamos a usa uno o dos caracteres como alias de una tabla, que fuerzan al programador a memorizarla, a no ser que sea un alias bien descriptivo. Todavia los sigo usando para crear consultas nuevas, por que cuando estas en el tema te acordas, pero cuando pasa el tiempo y tenes que revisar nuevamente el codigo ya no te acordas y tenes que bucear en entre las lineas hasta encontrar a que tabla le corresponde ese alias.

Hay alguna forma de estandarizar esto? o es mejor no usar alias?

[roman]

a no ser que sea un alias bien descriptivo


Justamente, si uno tiene que pensar en un alias descriptivo entonces el nombre del campo no era suficientemente descriptivo en primer lugar.

Desde mi punto de vista los alias son más bien para resolver conflictos de nombres coincidentes de campos provenientes de tablas distintas o bien para proveer nombres a campos calculados.

En el primer caso suelo prefijar el nombre del campo con el nombre de la tabla en lugar de usar alias. Es generalmente más largo de escribir pero a mi me facilita la posterior revisión de la consulta. Uso alias sólo en consultas "al momento", que difícilmente voy a reutilizar y prefiero ahorrar escritura usando alias.

// Saludos

[mamcx]

Totalmente de acuerdo. En Code Complete (http://www.cc2e.com/) se da un tip muy importante: Si se pone un comentario para EXPLICAR que HACE el codigo es que obviamente el codigo esta mal escrito. En vez de poner el comentario (o alias o lo que sea) se debe modificar el codigo. Los comentarios utiles son los que explican el PORQUE se hace este codigo (como por ejemplo: HACK: Esto es para evitar un error porque FOO es asi y BAR es asa) o algo por el estilo....