Estándar de Base de Datos
Se que los estándares no son tan rígidos para poner los campos de una tabla, existen varios, ¿pero quisiera saber con la experiencia que tienen cual es el mejor?
En estos momentos tengo 2 pero no se cual elegir:
Por ejemplo:
Tabla: Persona
Campos:
Código (PORQUE)
Nombre
Apepat
Apemat
Dirección
Email
Tabla: Carro
Campos
Código (PORQUE)
Marca
Modelo
Prscod (FK)
La otra forma es:
Tabla: Persona
Campos:
Código (PORQUE)
Nombre
Apellidopaterno
Apellidomaterno
Dirección
Email
Tabla: Carro
Campos
Código (PORQUE)
Marca
Modelo
Personacodigo (FK)
¿Cuál de los 2 es lo mejor, lo más utilizado, lo más estándar, etc?, la única diferencia es que uno tiene el estándar de 3 letras iniciales.
KERNEL/TEG
En estos momentos tengo 2 pero no se cual elegir:
Por ejemplo:
Tabla: Persona
Campos:
Código (PORQUE)
Nombre
Apepat
Apemat
Dirección
Tabla: Carro
Campos
Código (PORQUE)
Marca
Modelo
Prscod (FK)
La otra forma es:
Tabla: Persona
Campos:
Código (PORQUE)
Nombre
Apellidopaterno
Apellidomaterno
Dirección
Tabla: Carro
Campos
Código (PORQUE)
Marca
Modelo
Personacodigo (FK)
¿Cuál de los 2 es lo mejor, lo más utilizado, lo más estándar, etc?, la única diferencia es que uno tiene el estándar de 3 letras iniciales.
KERNEL/TEG
1 respuesta
Respuesta de gmenendez
1
Los nombres cortos formados por 3 letras iniciales de palabras significativas, a mi entender es práctico y cómodo pero sumamente inentendible, salvo que lo tengas muy bien documentado.
Personalmente prefiero los nombres descriptivos y auto-documentables incluso con separadores: apellido_materno, cod_persona, etc.
La experiencia que tengo es bajo Oracle y hasta sus generadores utilizan largas cadenas de string, para hacerlo más claro.
Ha llegado a generar varios prefijos para claves que se trasladan entre más de una entidad, ej. pre1_pre2_pre3_nombre_dato, o sea nosotros ponemos un atributo en una entidad y el generador sugiere varios prefijos concatenados al nombre del atributo como nombre de campo en una tabla.
No es muy práctico y muchos los acortamos pero es claro de donde proviene el campo y de que entidad es originaria.
Personalmente prefiero los nombres descriptivos y auto-documentables incluso con separadores: apellido_materno, cod_persona, etc.
La experiencia que tengo es bajo Oracle y hasta sus generadores utilizan largas cadenas de string, para hacerlo más claro.
Ha llegado a generar varios prefijos para claves que se trasladan entre más de una entidad, ej. pre1_pre2_pre3_nombre_dato, o sea nosotros ponemos un atributo en una entidad y el generador sugiere varios prefijos concatenados al nombre del atributo como nombre de campo en una tabla.
No es muy práctico y muchos los acortamos pero es claro de donde proviene el campo y de que entidad es originaria.
Entonces según tu experiencia se debería usar cadenas largas, por ejemplo actaConformidadCodigo y no actConCod... esos prefijos que hablas, ¿cuáles son? ¿Me podrías dar algunos ejemplos?
KERNEL/TEG
KERNEL/TEG
Disculpa el retraso en la respuesta pero estoy a full en varias cosas...
Respondiendo a tu respuesta: ¿Cuál te parece más claro y auto-documentable? Antes los nombres tenían restricciones por la escasez de recursos o el alto costo de estos pero hoy en día ya ningún lenguaje escatima en este detalle...
Como ej. te planteo esta situación:
1) Entidad E1 con alias ae1 y clave e1
2) Entidad E2 con alias ae2, clave e2 y la relación de foreign con E1 que también forma parte de la clave
3) Entidad E3 con alias ae3, clave e3 y la relación de foreign con E2 que también forma parte de la clave
Con la entidad E1 genero la tabla TE1 con un campo clave e1
Al generar la tabla TE2 con la entidad E2 se generan los campos
- e2
- ae1_e1
ambos formando la clave de TE2
Al generar la tabla TE3 con la entidad E3 se generan los campos
- e3
- ae2_e2
- ae2_ae1_e1
todos formando parte de la clave...
Así genera los nombres de campos de una tabla el generador de base de datos de Oracle...
¿Descriptivo, no?... a veces se hace incómodo cuando se hacen demasiado largo pero como te da la posibilidad de renombrarlos...
Respondiendo a tu respuesta: ¿Cuál te parece más claro y auto-documentable? Antes los nombres tenían restricciones por la escasez de recursos o el alto costo de estos pero hoy en día ya ningún lenguaje escatima en este detalle...
Como ej. te planteo esta situación:
1) Entidad E1 con alias ae1 y clave e1
2) Entidad E2 con alias ae2, clave e2 y la relación de foreign con E1 que también forma parte de la clave
3) Entidad E3 con alias ae3, clave e3 y la relación de foreign con E2 que también forma parte de la clave
Con la entidad E1 genero la tabla TE1 con un campo clave e1
Al generar la tabla TE2 con la entidad E2 se generan los campos
- e2
- ae1_e1
ambos formando la clave de TE2
Al generar la tabla TE3 con la entidad E3 se generan los campos
- e3
- ae2_e2
- ae2_ae1_e1
todos formando parte de la clave...
Así genera los nombres de campos de una tabla el generador de base de datos de Oracle...
¿Descriptivo, no?... a veces se hace incómodo cuando se hacen demasiado largo pero como te da la posibilidad de renombrarlos...
