[Tablas] ¿ Plural o singular ?

[marcoszorrilla]

Yo aunque creo que daba casi 500 pulsaciones por minuto y no es broma, pues me entrene pasando apuntes de clase, tacos y tacos de folios....

Los nombre de las tablas siempre los pongo en plural, partiendo de que antes que existieran los ordenadores y las tablas ya había ficheros, de cartón o metálicos...

Yo por ejemplo tenía y tengo aún un fichero de cartón en donde tenía fichas, cartulinas en blanco que iba rellenando con el nombre del autor del libro, título, editorial, páginas etc.

Que etiqueta contenía ese fichero: LIBROS

En las empresas los antiguos ficheros: CLIENTES, PROVEEDORES, EMPLEADOS...


Sin embargo suelo tener una tabla que se llama CONFIGURACION, porque en ella hay solamente un registro, que contiene los distintos campos configurables...

Un Saludo.

[ContraVeneno]

Empezado por dec

Por ejemplo, cuando se trata de relacionar tablas, es bastante sencillo referirte a campos como "user_id" y "link_id" sin ambiguedades, aunque, efectivamente, podría usarse el nombre de la tabla en estos casos.

En SQL, trato de evitar las ambigüedades utilizando un alias para los nombres de las tablas, por ejemplo:

Código SQL [-]
Select F.Factura, DF.Factura, F.Cliente, C.Cliente
From Facturas F
join DetalleFacturas DF on F.Factura = DF.Factura
join Clientes C on F.Cliente = C.Cliente

Aunque claro esta, que esto es a lo yo me he acostumbrado y se me hace muy fácil leer esa consulta.

Empezado por marcoszorrilla

Sin embargo suelo tener una tabla que se llama CONFIGURACION, porque en ella hay solamente un registro, que contiene los distintos campos configurables...

Y me atrevería a asegurar, que si fueran varios registros de configuración, la tabla se llamaría "Configuraciones"

[marcoszorrilla]

Así es ContraVeneno.

Un Saludo.

[[Delphius]]

Empezado por marcoszorrilla

Sin embargo suelo tener una tabla que se llama CONFIGURACION, porque en ella hay solamente un registro, que contiene los distintos campos configurables...

Empezado por ContraVeneno

Y me atrevería a asegurar, que si fueran varios registros de configuración, la tabla se llamaría "Configuraciones"

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,

[[Lepe]]

Empezado por Delphius

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

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 . Lo importante es tomar un criterio, todas en singular, o todas en plural, así no hay equívocos.

Saludos

[[Delphius]]

Empezado por Lepe

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

Saludos,

[[Al González]]

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

Solicitud
dtSolicitud
fmSolicitud
fmBusquedaSolicitud
rpSolicitud
btSolicitud
IDSolicitud

(Consistencia)

que con:

Solicitudes
dtSolicitudes
fmSolicitudes
fmBusquedaSolicitud
rpSolicitud
btSolicitud
IDSolicitudes

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