Club Delphi  
    Paypal   FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Otros temas > La Taberna
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 11-01-2008
caravena caravena is offline
Registrado
 
Registrado: ene 2008
Posts: 1
Poder: 0
caravena Va por buen camino
Existen dos políticas para nombrar las tablas

a) Con nombres singulares
b) Con nombres plurales

Donde ambas políticas malas : D.

El modelo entidad relación pretende representar la realidad. Si se ve de ese punto de vista lo adecuado sería utilizar los nombres en plural. Sin embargo, si se utiliza esta política puedes caer en este problema: ¿Qué sucede si se utilizan nombres de tabla compuestos?.

Supone que quieres nombar "colores de auto". En plural disponemos de las siguientes posibilidades: "colores_autos", "colores_auto" (solo nombrando dos posibilidades aplicables). Esto *ya* es ambiguo, fácilmente puedes caer en un error cuando programes por no recordar como se llama tu tabla. Cuando se esta programando tienes un conjunto de recursos que utilizas para enlazar un objetivo mayor. Claramente tu concentración se centra en la problemática mayor y solo deseas utilizar los recursos que dispones (Herramientas del lenguaje, objetos, etc.) Sin embargo si desbirtúas tus esfuerzos en racionalizar como estan creadas tus recursos desperdicias tu tiempo e incurres en errores.

Por otra parte, si utilizar en singular *no* dejas espacio a ambiguedades, solo queda una opción "color_auto". Si bien este nombre no representa la realidad, ayudará mucho a la programación, ya que claramente sabras el nombre y podrás enfocarte en la problemática que te encuentas en ese momento (programar, no modelar).

Entonces la pregunta correcta sería: ¿Cual de ambas políticas es más beneficiosa?

Según lo argumentado anteriormente yo me inclinaría en nombrar las tablas de manera singular. Ya que en la etapa de modelamiento, mayor abstración, se entenderá igualmente que información se almacenará en esa entidad, en cambio cuando estes muy concentrado programando no recordaras cual es nombre de la tabla y es muy probable que se incurra en un error y pérdida de tiempo.

En otras palabras es una cuestion de costo/beneficio:
a) Nombrar las entidades de manera plural
Beneficio: Representa la realidad en un alto grado de abstracción
Costo: Dificultará enormemente la programación en situaciones medianamente a altamente complejas.

b) Nombrar las entidades de manera singular
Beneficio: Facilitará la programación
Costo: No representa perfectamente la realidad en el modelo de entidad relación, pero sin embargo en ese nivel de abstracción, no complicará el modelamiento ya que se deduce de igual manera que contendrá la entidad.

Última edición por caravena fecha: 11-01-2008 a las 17:47:45.
Responder Con Cita
  #2  
Antiguo 11-01-2008
DJ VMan DJ VMan is offline
Miembro
 
Registrado: jun 2003
Ubicación: Iquique - Chile
Posts: 81
Poder: 23
DJ VMan Va por buen camino
Cita:
Empezado por caravena Ver Mensaje
Por otra parte, si utilizar en singular *no* dejas espacio a ambiguedades, solo queda una opción "color_auto". Si bien este nombre no representa la realidad, ayudará mucho a la programación, ya que claramente sabras el nombre y podrás enfocarte en la problemática que te encuentas en ese momento (programar, no modelar).
es decir, hay una clara separación de la programación y del modelamiento. y el problema NO es en el modelamiento, es la programacion.
Cita:
Empezado por caravena Ver Mensaje
En otras palabras es una cuestion de costo/beneficio:
a) Nombrar las entidades de manera plural
Beneficio: Representa la realidad en un alto grado de abstracción
Costo: Dificultará enormemente la programación en situaciones medianamente a altamente complejas.
"enormemente" es un tanto exagerado...no? puede que lo dificulte, puede que no. Hago mías las palabras de @Fate, depende del contexto.
Cita:
Empezado por caravena Ver Mensaje
b) Nombrar las entidades de manera singular
Beneficio: Facilitará la programación
Costo: No representa perfectamente la realidad en el modelo de entidad relación, pero sin embargo en ese nivel de abstracción, no complicará el modelamiento ya que se deduce de igual manera que contendrá la entidad.
"no complicará el modelamiento" también depende, nuevamente sale al aire "depende del contexto".

claramente son formas distintas de ver el problema, y es porque el problema se produce en el proceso de digitación de código, no en el modelamiento. Si se tiene esto claro, se puede optar por una o por otra, o por ambas (como mencione más arriba).
__________________
- Si tienes un problema que tiene solución ¿porque te preocupas?
- Si tienes un problema que no tiene solución ¿porque te preocupas?
Responder Con Cita
  #3  
Antiguo 11-01-2008
Avatar de Lepe
[Lepe] Lepe is offline
Miembro Premium
 
Registrado: may 2003
Posts: 7.424
Poder: 31
Lepe Va por buen camino
Ambas formas tienen un problema no comentado.

Después de terminar el programa tu cliente quiere una modificación urgente que echa por tierra tu nomenclatura (da igual si usas plurar o singular, tu cliente será capaz de destrozar ambas), ¿qué hacemos? ¿renombramos todo?

No hombre, sería una locura, ponemos un comentario con la fecha indicando el requerimiento y listo , aunque todo queda desajustado. Meses después, será un caos total.

Ahora mismo programas en plural, después te das cuenta de que usando el singular podrás ahorrar muchas líneas de código, hecho que aumentará tu productividad. Años después trabajas con una herramientas que a partir de la cardinalidad de una relación, te crea los objetos en plural o singular, o te abstrae de todo el proceso [...] ¿donde voy? Como dijo un compañero antes, no importa el método, lo que importa es que uses un método.

Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente,
se lo volveré a explicar hasta que no lo entienda, Gracias.
Responder Con Cita
  #4  
Antiguo 11-09-2014
Avatar de RONPABLO
[RONPABLO] RONPABLO is offline
Miembro Premium
 
Registrado: oct 2004
Posts: 1.514
Poder: 23
RONPABLO Va por buen camino
Ya han pasado varios años desde que se inicio este hilo y hoy lo revivo porque me gustaría saber como siguen... ¿han cambiado o continúan nombrando las tablas como lo hacían antes?, yo sigo con los nombres en plural y con una llave única de tipo entero llamada Id, aunque he visto que unos recomienda llamar la llave única con el nombre de la tabla en singular y terminada en Id, algo así como:

Cita:
Perfiles
PerfilId
Nombre

Permisos
PermisoId
Nombre

PermisosPorPerfiles
PermisoPorPerfilId
PermisoId
PerfilId


Aunque yo prefiero algo así como:
Cita:
Perfiles
Id
Nombre

Permisos
Id
Nombre

PermisosPorPerfiles
Id
PermisoId
PerfilId


se me hace más ágil a la hora de hacer consultas.
__________________
"Como pasa el tiempo..... ayer se escribe sin H y hoy con H"
Responder Con Cita
  #5  
Antiguo 11-09-2014
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
Antiguamente usaba el plural pero posteriormente preferí el singular.

Por ahí se argumentó que se debe usar el plural porque se tendrán, por ejemplo varios clientes y no uno sólo. Pero ese mismo argumento nos llevaría a nobrar las clases en plural, TClientes.

Se argumentó también, en pro del plural, que el MER intenta reflejar la realidad. Y es por ello que prefiero el singular. Cuando modelo el sistema me interesa saber qué quiero de un cliente, qué representa una factura, qué atributos tiene un usuario, y no el conjunto de clientes, facturas o usuarios. Es decir, en el MER, lo que interesa es la entidad en sí, y no el contenedor de esas entidades.

Por otra parte, el uso del singular es consistente en las consultas SQL al hacer relaciones:

Código SQL [-]
select factura.*
from ...
where factura.clienteId = cliente.id

Si usamos el plural:

Código SQL [-]
where facturas.clienteId = clientes.id

¿qué estamos diciendo? ¿El id de todos los clientes? ¿El atributo clienteId de todas las facturas?

En cuanto a los campos, me parece redundante incluir el nombre de la tabla. ¿usuario.usuarioId? Pues, ¿de quién más iba a ser ese id de la tabla usuario?

Pero, desde luego, esas son las razones que a mi me sirven y no necesariamente todos lo ven de igual manera. Lo realmente importante es ser consistente.

// Saludos
Responder Con Cita
  #6  
Antiguo 11-09-2014
Avatar de ContraVeneno
ContraVeneno ContraVeneno is offline
Miembro
 
Registrado: may 2005
Ubicación: Torreón, México
Posts: 4.740
Poder: 26
ContraVeneno Va por buen camino
sopas... ya me hiciste dudar Roman... Yo estoy optando por los nombres de las tablas en plural y definitivamente sí es redundante volver a poner otra vez el mismo nombre de la tabla

Pero con lo que comentas, me parece que tienes razón en poner el nombre de la tabla en singular. Aunque como siempre uso "alias", ni cuenta me doy:
Código SQL [-]
From Facturas F
join clientes C on F.ClienteID = C.ID
__________________

Responder Con Cita
  #7  
Antiguo 11-09-2014
Avatar de Casimiro Noteví
Casimiro Noteví Casimiro Noteví is offline
Merodeador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.669
Poder: 10
Casimiro Noteví Tiene un aura espectacularCasimiro Noteví Tiene un aura espectacular
Tabla en plural. Campos en singular.
Código:
tbClientes
  id
  nombre
  telefono

tbArticulos
  id
  nombre
  precio

tbVentas
  id
  numero  
  fecha
  idcliente
  
tbLineasVentas
  id
  idventa
  idarticulo
En cuanto a los nombres, alias, etc. nunca los uso, salvo que estén involucradas varias tablas
Código SQL [-]
select id, numero, fecha from tbVentas
Código SQL [-]
select v.fecha, v.cliente, c.nombre
from tbventas v
inner join tbclientes c on c.id=v.idcliente

Última edición por Casimiro Noteví fecha: 11-09-2014 a las 22:37:23.
Responder Con Cita
  #8  
Antiguo 11-09-2014
Avatar de RONPABLO
[RONPABLO] RONPABLO is offline
Miembro Premium
 
Registrado: oct 2004
Posts: 1.514
Poder: 23
RONPABLO Va por buen camino
Cita:
Empezado por roman Ver Mensaje
Antiguamente usaba el plural pero posteriormente preferí el singular.

Por ahí se argumentó que se debe usar el plural porque se tendrán, por ejemplo varios clientes y no uno sólo. Pero ese mismo argumento nos llevaría a nobrar las clases en plural, TClientes.

Se argumentó también, en pro del plural, que el MER intenta reflejar la realidad. Y es por ello que prefiero el singular. Cuando modelo el sistema me interesa saber qué quiero de un cliente, qué representa una factura, qué atributos tiene un usuario, y no el conjunto de clientes, facturas o usuarios. Es decir, en el MER, lo que interesa es la entidad en sí, y no el contenedor de esas entidades.

Por otra parte, el uso del singular es consistente en las consultas SQL al hacer relaciones:

Código SQL [-]select factura.* from ... where factura.clienteId = cliente.id


Si usamos el plural:

Código SQL [-]where facturas.clienteId = clientes.id


¿qué estamos diciendo? ¿El id de todos los clientes? ¿El atributo clienteId de todas las facturas?

En cuanto a los campos, me parece redundante incluir el nombre de la tabla. ¿usuario.usuarioId? Pues, ¿de quién más iba a ser ese id de la tabla usuario?

Pero, desde luego, esas son las razones que a mi me sirven y no necesariamente todos lo ven de igual manera. Lo realmente importante es ser consistente.

// Saludos
Me viene unas duda...
1: En:
Código SQL [-]
Select
   Numero, Fecha, Valor, Descripcion
From Facturas
where Fecha between :f1 and :f2

El Resultado es un listado de varias facturas.

2. Cuando dice

Código SQL [-]
where facturas.clienteId = clientes.id

Veo que queda claro. ¿Porque? porque al decir Facturas.ClienteId entiendo que esta sacando un dato independiente (ClienteId) de un lugar donde hay muchos datos (Facturas)
Concuerdo con Roman de que poner en el nombre del campo sin usar algo que puedo inferir de el nombre de la tabla, osea si la tabla Facturas tiene un campo Id sobra llamarlo IdFactura o FacturaId
__________________
"Como pasa el tiempo..... ayer se escribe sin H y hoy con H"
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Tablas dbf patorecalde Tablas planas 4 04-12-2008 00:05:58
tablas en sql server demasiadas tablas yeison Cristman SQL 8 10-08-2006 16:26:36
Tablas Dbf keys Conexión con bases de datos 2 03-11-2005 09:32:57
Tablas dbf. keys Conexión con bases de datos 2 13-10-2005 17:10:51
Dll con tablas brandolin OOP 1 19-08-2003 16:12:07


La franja horaria es GMT +2. Ahora son las 03:56:16.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi