Curiosamente a esa tabla yo la llamaría (y de hecho asi la llamo) CONFIGURACION. Y a pesar de que el contexto me indicase que se debe llevar un histórico de estas configuraciones, y si el diseño y análisis me indica, que es factible mantener en cada registro los cambios que se fueron llevando a cabo... aun así... la seguiría llamando Configuración. Pues, el contexto o dominio, me da la pauta de que se espera en un momento determinado una única configuración.

Es decir que el nombre de mis tablas deben indicar el uso que se le:
Clientes: se espera operar con varios clientes. El contexto indica que es posible que en un "mismo instante de tiempo" se atiendan a varios clientes.
Configuración: se espera trabajar con un una unica configuración válida. El dominio indica que sólo una configuración esta activa durante un "período de tiempo", si bien es posible que a lo largo de toda la actividad pueda cambiarse EXISTE SOLO UN REGISTRO VALIDO, EL ULTIMO INGRESADO.

Suena un poco enrreversado, pero ultimamente mi cabeza está trabajando de ese modo.

Saludos,

KISS: Keep It Simple Stupid ;)

Cuando estás enfrascado en un SQL complejo (facturas no pagadas con iva tal, con/sin vencimientos, agrupadas por cliente, etc), en lo último que piensas es en el nombre de la tabla, al final obtienes en ejecución un error porque la tabla no existe; me saca de quicio :D. Lo importante es tomar un criterio, todas en singular, o todas en plural, así no hay equívocos.

Saludos

Muy bien dicho... palabras exactas, palabras más simples que KISS no hay... pero ten en cuenta a quien estás hablando: a mi ¡El tipo más enrreversado y complicado!:D

Saludos,

Por qué es mejor en singular
 

¡Vaya! Sí que se han dado bastantes puntos de vista.

Lo que más me extraña es la incipiente defensa que se ha hecho del estilo singular.

Para mí no tiene vuelta de hoja. El estilo singular es más eficiente. Llevo poco más de un año empleándolo y no cabe duda de que te evita muchos problemas y hace que tu código sea más consistente. No se trata de gustos, mañas y otras mezquindades. Se trata de empatar la lógica con la práctica de la manera más simple posible. Todo parte del concepto de entidad, aunque la lógica lingüística deje caer el terrible peso de la costumbre sobre nosotros.

Por ejemplo, tenemos una entidad llamada "Solicitud", por lo tanto tenemos una tabla llamada Solicitud, un conjunto de datos llamado dtSolicitud, una forma de captura llamada fmSolicitud, una forma de búsqueda llamada fmBusquedaSolicitud, un reporte llamado rpSolicitud, un botón llamado btSolicitud, una llave foránea IDSolicitud, etc. La entidad solicitud va en el nombre de cada cosa que se relaciona con ella.

Al principio estaba algo renuente a usarlo. Pero creo que es parte del proceso de madurez de un desarrollador ir aceptando algunas sanas prácticas como esta. Recuerden que el principio de simplicidad y consistencia es fundamental en todo proceso sistemático.

Programática o sistemáticamente podemos, con menor esfuerzo, hacer más con:
(Consistencia)

que con:
(Inconsistencia)

Por si fuera poco, hace más inteligible el código, no sólo en sentencias SQL, sino también en código de programa:

Código Delphi [-]
{ Poniendo en False el campo Vigente de UNA solicitud }
dtSolicitudVigente.Value := False;

Código Delphi [-]
{ ¡¡ ¿Estamos poniendo en False el campo Vigente de varias solicitudes? !! }
dtSolicitudesVigente.Value := False;

La costumbre y el uso natural de una lengua nos invitan a ajustar los procesos sistemáticos a lo que llamamos vida real. Lo cual no está mal, de eso se trata el hacer software. Pero no hay que tratar de imponer el estilo humano a la lógica de programación, porque ésta ya viene con la semilla del suyo propio: uno más consistente, simplificado y eficiente para el ambiente donde vive. De uno depende qué tan bien cuidar a esa semilla y a la planta que de ella hacemos nacer.

Un abrazo singular.

Al González. :)

Debatir el nombre dado a las tablas, en este club tan plural, resulta muy singular.

Creo que es un asunto muy singular, tratado por una gran pluralidad de foristas.


Un Saludo muy singular para esa gran pluralidad.

Si se ha formado este debate.... esperad a las dudas del diagrama de clases :D

Saludos

a mi entender (y el de otros tambien), la cosa es al revés. y la explicación es simple: el modelamiento de bases de datos pretender representar la realidad.

Por tanto, si en un libro guardo información de personas -por ejemplo- lo natural es denominar la tabla "personas" y no "persona". Ya que en esa tabla no habrá información de 1 si no que de muchas personas.

Singular
 

Yo pienso que es singular y aqui el porque....

Si, tienes muchos clientes, pero depende del contexto, es decir, si tu tabla almacena tu lista de clientes, pues es correcto en plural, pero si cada tabla es una entidad de un cliente(como por ejemplo un cliente de un banco) pues es singular ya que cada instancia de esa tabla es un unico cliente

Como bien dices depende del contexto, es decir, de la realidad y volvemos al punto que mencioné: el modelamiento representa la realidad.

Si entendí bien tu ejemplo: clientes de un banco, luego tendremos cuentas (de clientes), créditos (de clientes) y asi sucesivamente. puede que me equivoque, porque tendría que empaparme del problema para representarlo bien.

En general, es perfectamente posible que se usen ambos, singulares y plurales y dependerá de lo que se esté modelando, de la realidad (el contexto).

Por cierto, no si vieron el link que puse. Es una converción que usa Oracle, y si lo hace oracle...por algo será...no? recomiendo tambien ver los links que aparecen al final de ese enlace.

Ahora bien, entiendo perfectamente que el uso de "eses" complique a los programadores al momento de digitar código. Claro, en ocasiones una S y en otras no. Se entiende. Pero eso es programación, yo estoy hablando de modelamiento de Bases de Datos.

Una alternativa es: poner en singular los objetos que se enlazan a la BD*, pero la BD queda intacta. Así se lograrían ambos casos, cubriendo ambas "necesidades": plurales representando la realidad en la BD, y singulares para facilitar la programación.

Ej:

nombre de tabla en la BD: clientes
nombre de campo en la BD: nombre
nombre del objeto de enlace a la tabla* en la aplicacion: cliente
nombre de campo en la aplicación: nombre

* no recuerdo como se llaman en delphi (hace como 7 años que dejé delphi :D)

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.

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.
"enormemente" es un tanto exagerado...no? puede que lo dificulte, puede que no. Hago mías las palabras de @Fate, depende del contexto.
"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).

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? :D

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

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:


Aunque yo prefiero algo así como:

se me hace más ágil a la hora de hacer consultas.

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

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 :rolleyes:

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

Tabla en plural. Campos en singular.
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

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

Odio los alias :D

Al principio usaba alias pero me di cuenta que revisar una consulta SQL hecha meses o años atrás con alias es extenuante. Vamos, que usar alias para tablas del tipo c, u, f es como nombrar a tus variables var1, var2, var3.

En algunas ocasiones uso alias para campos para alguna necesidad particular en la que quiera usar un sinónimo, pero siempre alias que tengan un significado.

En tablas, sólo cuando es absolutamente necesario, por ejemplo, cuando una misma tabla se relaciona varias veces en la misma consulta.

// Saludos

Sobre los alias yo siempre los uso ya que me de agilidad, y voy dando una cierta complejidad según la consulta, por ejemplo:

1. Para una consulta simple o una consulta con varias tablas pero con iniciales diferentes pongo el primer caracter de cada tabal:

Código SQL [-]
Select u.Nombre, u.Documento From Usuarios u where u.id = :id

Select 
     u.Nombre, u.Documento, f.Numero 
From Usuarios u 
inner join Facturas on f.UsuarioId = u.id 
where f.fecha between :f1 and :f2

2. Para consultas donde van más de 2 tablas o para 2 tablas con iniciales similares uso alias de tres letras, por ejmeplo:

Código SQL [-]

Select 
     usu.Nombre, usu.Documento, fac.Numero, fdp.Descripcion as formaDepago 
From Usuarios usu 
inner join Facturas fac on fac.UsuarioId = usu.id 
inner join FormasDePago fdp on fac.FormaDePagoId = fdp.id
where fac.fecha between :f1 and :f2