Nomenclatura y estandares

[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

[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

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

Empezado por Mauro.NET

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