Nomenclatura y estandares

[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 ).

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

Código SQL [-]
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

// 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

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 (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.

[roman]

Empezado por ContraVeneno

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?

// 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.

Empezado por roman

...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 ...

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.

Empezado por ContraVeneno

...Supongo que leímos el mismo libro o algo similar porque utilizamos los mismos estándares. Saludos Al ...

Hombre, prefiero no decir cuántos libros de informática he leído . Quizá sea que un servidor también vivió en Torreón . Y ya de paso te pido una disculpa por lo que pensaba de tu ciudad hace ocho años .


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.

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

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" , 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