FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Norma en Bases de Datos
Hola a todos. No sabía si poner esto aqui o en debates, al final me decidí por aqui. Es un poco largo pero interesante...ahi va:
Conversando y conversando con un primo, entramos en la siguiente discusión: Yo digo que la mejor forma de trabajar los nombres de las tablas es asi: NombreTabla NombreCampo1 NombreCampo2 etc ejemplo: Clientes Nombre Apellido etc. El dice que "LA NORMA" dice que es asi: NombreTabla NomTabNomCamp1 (o NomTab-NomCamp1) NomTabNomCamp2 (o NomTab-NomCamp2) etc. ejemplo: Clientes Cli-Nom Cli-Ape etc. Esto, según el, por dos grandes razones: 1.- porque los motores de base de datos (SQL Server, que es la que aprendió inicialmente) se "confunden", por tanto cuando se hace una SQL que referencia a varias tablas, y en las cuales existen tablas con campos que se llaman igual, el motor "se confunde". 2.- porque es más fácil la lectura. Por ejemplo si se está codificando en algún punto y se lee cli-nom, se sabrá automáticamente que es el campo 'nombre' de la tabla 'clientes'. Yo por mi parte, no creo esto. Pienso que no debiese "confundirse" el motor de base de datos, y si lo hace me merece bastante desconfianza la BD. De hecho, y al menos, Access y MySQL no se comportan de esa forma. Pienso que es más confuso de esa forma, puesto que casi nunca se va a tabrajar con los campos sólos, siempre se trabaja 1º con la tabla y luego con el nombre del campo, por ejemplo Clientes.Nombre Otra cosa, esta supuesta "norma" me da la impresión que se ocupaba en BD antiguas en donde el nombre no podía superar un cierto largo. De hecho, lo veo a menudo en programadores antiguos (quise decir de cierta experiencia..jeje). Pero hoy la cosa es distinta, y a mi parecer es mucho más fácil leer y entender Clientes.Direccion que Clientes.cli-dir...por ejemplo. PREGUNTA: ¿Existe alguna norma al respecto? ¿Cual es? ¿Donde está? |
#2
|
|||
|
|||
yo soy partidario del primer esquema, ya que cuando uno esta haciendo un diceño orientado a objetos pienza en estos y sus atributos, de modo tal que las tablas quedan representando las entidades en forma practicamente identica al diceño. Otra cosa es que es mucho mas rapido y simple no tener que estar repitiendo lo extensos nombres y dejarle ese problema al DBMS.
Solo es una opinion
__________________
Marín Ignacio Borthiry (Viet) - "El hombre arriesga su vida cada vez que elije y eso es lo que lo hace libre" ;) |
#3
|
||||
|
||||
Hola, en realidad no existe norma ni standar que marque como hacerlo, y creeme, aunque ya llevo algunos años programando contra BBDD, nunca creo haber tenido problemas con la longitud de los nombres.
Lo que sí marco, (y esto lo aprendí o me lo inculcó un programador, que aunuqe empirico y sin carrera, tenía los coj~~¬€ tan pelaos; que sabía un montón de práctica) una serie de reglas personales a la hora de calificar las entidades con las que trabajas. 1) En principio, los nombres de campos de una tabla es importante que sean de la misma longitud. ¿Porqué?, porque a la hora de leer el código es mucho más facil cuando tienes el nombre del atributo totalmente calificado, P.e.: NombreTablaNomCli_cli NombreTablaDirCli_Cli NombreTablaTelCli_cli 2) Después, tambien es importante como habrás observado que el nombre del atributo termine con un acronimo o abreviatura de la tabla a la cual pertenecen, en el anterior caso la tabla hipotetica de clientes. 3) utilizar máximo, (siempre q sea posible), tres letras por nombre descriptivo, es decir, Nombre cliente de la tabla cliente := Nom + Cli + _ + Cli. Separando con un subrayado el sufijo ientificativo de la tabla. 4) Cuando utilices variables de trabajo, nomvar_w. de este modo cuando encuentres la _w, ya sabes que son variables. En fin hay un conjunto de cosas que aunque no son estandares si ayudan a cuando lees código de hace tiempo o ajeno siempre que se cumplan minimamente estas "reglas". por esperiencia te diré, que al principio dices : - este tio!!!!! ; pero mis compañeros de PFC, compañeros de prácticas, y actualmente los becarios que pasan por mi empresa se apoyan en esto y la verdad es que siendo una cosa tan sencilla, la cosa facilita el tema. De ahí a que si los SGDB se rayan o nó, no te lo puedo decir, la verdad no he tenido nunca ese tipo de problemas. Bueno, espero haberte ayudado. Un aludo.
__________________
El meu país és tan petit, que des de dalt d'un campanar es pot veure el campanar veí. |
#4
|
|||
|
|||
hola Cabanyaler:
sin ánimo de molestar, sino que debatir (para asi mejorar o aprender) es que replico: Cita:
NombreTabla.NombreCampo (nótese que es CaseSensitive (no me acuerdo como se le dice en español)) p.e. : Clientes.FonoParticular, y no : clientes.fonoparticular y/o CLIENTES.FONOPARTICULAR. Porque? porque encuentro que al leer lo primero se entiende, se lee visualmente más rápido que las otras. Aunque lo que tu planteas es igualmente válido, me cuesta pensar, y de hecho me pasa, que no puedo leer con facilidad un campo que contenga sólo 3 letras de su largo completo. Cita:
Por ejemplo : Clientes.Direccion a mi me parece bastante claro....o no? Cita:
vNombre : variable normal, comunmente usada en los functions o procedures. vlNombre : variable local, aplicada a la unidad en donde se creó. vpNombre : variable pública. pNombre : parametro. etc Nótese que siempre ocupo Mayúsculas Iniciales (CaseSensitive). En Gral. Se nota que es necesario definir una estructura de codificación tanto para nombres de variables, funciones, procedimientos, campos, tablas...etc. Obviamente, para facilitar su lectura. Por lo que he podido ver, estas varían de acuerdo a la enseñanza dada ("herencia de codificación"), como por gustos muy personales. Por ello, cuando se trabaja en grupo es indispensable NORMARLO. Esto, si tu eres el jefe, es fácil ya que todos tendrán que acatar. Es por ello que puse este hilo. Para tratar de definir alguna estructura indipendientemente seas Jefe o Empleado. Indistintamente cualquiera sea el caso/gustos/enseñanza/trabajo/poderes, pienso (muy humildemente) que cualquier norma no ha de cortar o truncar un nombre. Así como tambien, cualquier norma que vaya encontra de la lectura natural, irá en contra de una buena codificación. uf!... ...me cansé nos vemos! |
|
|
|