[Tablas] ¿ Plural o singular ? [Archivo]

Lepe

23-11-2007, 22:38:45

Pues yo opino que singular, ¡¡ toma ya !!

Sobre gusto los colores, pero si después tengo que hacer una clase, normalmente le llamaré TFactura, y ya tenemos el lío padre, en delphi singular, en la BBDD plural.

Y aunque no viene al caso, la clave primaria siempre que se pueda tendrá el formato :'ID' + nombretabla

El campo principal, Por ejemplo, de la tabla "cliente" se llamará igual que la tabla, useasé: Cliente (nada de "Nombre" "Denominacion", etc).

Ahora mismo tengo un diseño así, un simple Frame con un dbnavigator, un grid y el botón de imprimir, me permite administrar 5 tablas distintas con solo pasar el nombre de la tabla ;) (otra razón más para que sea en singular).

Si tienes que crear SQLs de update, insert, etc, usando esta nomenclatura es un juego de niños.

Las claves ajenas (foráneas) de igual nombre que la de su tabla de origen, por ejemplo:

tabla Cliente:
idcliente autoinc,
Cliente varchar 100

tabla Factura:
idFactura autoinc
Factura char(15) /* el número de factura */
idcliente (clave ajena)

Cuando se tienen muchas tablas, se agradece esta filosofía, porque tienes que recordar lo mínimo posible, las SQLs salen sin pensar.

PD: Me ha gustado mucho este tema, fijaté ;).

Saludos

dec

23-11-2007, 22:50:51

Hola,

Yo no tengo mucha experiencia en el tema, más que nada en PHP, pero, lo que hago es nombrar las tablas en plural, y, a cada campo, le añado el prefijo de la tabla en singular... es decir, por ejemplo:

Tabla: users

Campos: user_id, user_name, user_email, etc.

:)

AzidRain

23-11-2007, 23:10:00

Obviamente es un Plural...¿Por que?

Por definición una tabla es un conjunto de filas (y columnas), inclusive nadie diseña pensando en un cliente, una factura, un albarán...siempre son más de uno por lo que el plural viene siendo más que obvio.

Ojo, no confundirse con el modelo de objetos ya que ahi si la cosa puede cambiar. Así pues tendremos una clase cliente, una clase factura, y una clase albarán...pero estamos hablando de mundos distintos, lo que para el modelo E-R es una tabla Facturas para el modelo OO es una Colección de objetos factura. En la vida real siempre decimos "pásame las facturas" y lo que nos dan es un folder (carpeta) que contiene varias "instancias" de la misma cosa, una factura por lo que el concepto de un objeto que sea a la vez muchos pues no cabe. Por eso tenemos un TFactura y no TFacturas, pero si un TFolder que contiene muchas TFactura.

Pero bueno, la conclusión lisa y llana es: Sí, las tablas deben nombrarse en plural.

BlueSteel

23-11-2007, 23:12:59

Yo opino como Lepe...

Debe ser Singular...

comparto lo de poliburro, una empresa tiene Cliente o Clientes?

Sigamos con la Tabla CLIENTE.. (es mi diseño..:D)

pero si lo miras de la perpectiva de que una tabla de almacena datos y que ese conjunto de campos es un registro, entonces como te refieres a ese cliente

Clientes (Juan Perez.. direccion x, Telefono x ) o te refiere como

Cliente (Juan Perez.. direccion x, Telefono x )

Mirandolo desde el punto de vista semántico.. cada registro se analisa en forma independiente... por lo cual (a no ser que imprimas).. cuando realizas un ingreso de datos (que no sea masiva..).. estas ingresando 1 cliente.. y no 1 clientes....

También recuerdo que algun ramo de la Univ. me indicaron que se debe considerar el nombre de la tabla en singular...

BlueSteel

23-11-2007, 23:25:08

completando lo anterior.. me puse a buscar información dentro de mis apuntes. y pude encontrar esto

TEMA: CONVENCIONES DE NOMBRES

- Los nombres de las tablas deben ser únicos dentro de un sistema.
- Los nombres de las columnas deben ser únicos dentro de una tabla.

- Seleccione los nombres de tablas y columnas con cuidado.

- Los nombres de tablas y columnas no sólo identifican, sino también describen cada tabla y columna.

- Seleccione los nombres de tablas y columnas en conjunto con los usuarios. (muy poco utilizado)

- Elija nombres de tablas y columnas que sean lo más cortos posibles.

- Acrónimos que son de entendimiento común son válidos; sin embargo, se deben evitar formas crípticas o indescifrables.

Use el singular en vez del Plural.

La experiencia indica que (al menos en Inglés) el singular es más compatible con el modo en que comúnmente se usan los nombres de tablas y columnas en discusiones y documentación escrita del sistema.

Lepe

23-11-2007, 23:55:14

Tabla: users

Campos: user_id, user_name, user_email, etc.

:)

... Hombre... con tus 400 pulsaciones por minutos te lo puedes permitir, yo soy más lento :p

Por definición una tabla es un conjunto de filas.
Pero bueno, la conclusión lisa y llana es: Sí, las tablas deben nombrarse en plural.

El nombre de la tabla que yo propongo es singular y también se refiere a un conjunto de filas, es decir, si la definición ya implica el concepto de "conjunto" ¿por qué ponerlo en plural?

No sé AzidRain, has sonado muy tajante en tu afirmación. Yo, desde luego, me he basado en mi opinión personal y mi experiencia (de hecho recuerdo un sistema de BBDD en oracle de una multinacional, realizado por auténticos gurús de la programación y diseño; todas las tablas eran en singular). Al principio me impactó eso de que todo se llamara igual, pero cuando ví unas 300 tablas, comprendí el diseño.

Actualmente uso muchos trucos de aquel sistema.

Saludos

ContraVeneno

24-11-2007, 01:03:30

La experiencia indica que (al menos en Inglés) el singular es más compatible ...
Pues ese será el punto mi buen BlueSteel, será que al menos yo, no programo en inglés :D y para mi, es mas compatible pensar en la tabla de clientes, que en la tabla cliente. Así, mis consultas salen solas :p

Tabla: users
Campos: user_id, user_name, user_email, etc.

... Hombre... con tus 400 pulsaciones por minutos te lo puedes permitir, yo soy más lento :p

Aqui no me queda más que decir que: opino lo mismo que maese Lepe. Con mis 50 palabras por minuto no puedo darme ese lujo. :D

Actualmente uso muchos trucos de aquel sistema.

Ese tendría que ser el punto, aprender trucos de aquí y de allá, y que cada quien se adapte a su estilo de programación, o al estilo de programación que maneje el grupo de trabajo (que generalmente lo define el lider de proyecto).

En fin, ya lo dice el viejo y sabio proverbio chino:
Cada quien sus cochinas mañas :D

eduarcol

24-11-2007, 01:40:16

aqui si son lo maximo, todo un debate por saber si la tabla debe llevar una s o no :cool:

yo opino el plural, se refiere a lo que vas a almacenar, y esperemos que al empresa no almacene cliente sino clientes, de lo contrario ni pa que el sistema

Delphius

24-11-2007, 03:58:49

Buenas...
Yo pienso que debe responder al contexto del problema. Y por lo general, esto conduce una percepción pluralista de las entidades. Considero que si el nombre refleja un hecho del dominio, del contexto, es más útil para llevar a cabo el correcto diseño y mantenimiento.

Ahora, ese contexto y problema debe ser aceptado por quienes componen el equipo de proyecto (si es uno... bueno... no hay drama). Si todos están de acuerdo a que es PEPE y no PEPITOS... pues que se llame PEPE. ¿Quienes deben participar? Todos: hasta el usuario final, que como dice Azid por lo general no se lo toma en cuenta. ¿Porqué debe participar? La respuesta, con esta pregunta: ¿Quien mejor para indicarnos el nombre adecuado que el sujeto o actor que está envuelto en el contexto?
Esto no es nuevo, ya lo han dicho pero puede que en ocasiones un integrante del equipo hace un cambio en X y si para alguien ese X es Y... pues vamos mal.

Curiosamente, a las tablas las nombro en castellano... pero cuando programo lo hago en inglés.:confused:

Lo que considero contraproducente para el equipo es que sea el jefe el que indique el estilo de programación. Para mi debe salir desde el grupo, y no de uno solo.

Por ahora, yo vengo declarandolas en plural a menos que el contexto me indique lo contrario. Pero ultimamente estoy tratando de conducir un diseño y estilo dirigido hacia el contexto o dominio. Antes, (cuando hacía practicas en la facultad) veía en los casos de tablas intermedias nombres como USUARIOS_VENTA. ¿Que representa USUARIOS_VENTA? Eso no me indica nada a mi... es más... dificulta entender el dominio. La nomeclatura debe adaptarse al contexto de modo que con una leída pueda entenderse que registra.

Saludos,

RONPABLO

24-11-2007, 04:56:05

Yo trabajo con el nombre de las tablas en plural, los campos en singular y con un auto numérico id, y cuando tengo un campo a manera de foreign key se llama en singular como la tabla a la que esta relacionada (ejemplo el campo que me relaciona con la tabla facturas se deberá llamar factura y es el mismo campo id en dicha tabla), no me gusta cuando una tabla tiene sus campos que empiezan con el mismo nombre de la tabla, en si por compatibilidad... yo se que siempre una tabla personas va a tener un campo nombre y no un perNombre.... en fin... son gustos

Delphius

24-11-2007, 05:20:49

Y si... es como dices: son gustos.

En cuanto a los campos, yo los llamo por las "propiedades" de la entidad a la que representa: Nombre, Color, etc... Exceptuando aquellos campos que son claves, hago así:
Si la clave es primaria: IDTabla[-s]
Si la clave es foranea: ID[Campo]Tabla[-s]

La idea es que el nombre haga referencia a la tabla. [Campo] Corresponde al nombre que se le debería asignar al identifiador. Por ejemplo el ID de un usuario podría ser el DNI, de modo que si si tenemos las tablas Usuarios y Ventas yo tengo: IDUsuario en la tabla Usuarios e IDDniUsuario en la tabla Ventas. Mi cerebro ya se acostumbró a interpretar y traducir esto:
IDUsuario: "Identificador del usuario", IDDniUsuario: "DNI del usuario"
[-s] Hace referencia a que se debe quitar la pluralidad. Noten que si bien la Tabla es USUARIOS, la clave queda sin la S.

La Tabla responde a un conjunto, pero es el campo que me indica la individualidad.

Puede parece un poco criptico, pero cuando uno se acostumbra...

Saludos,

dec

24-11-2007, 10:27:29

Hola,

Yo la verdad es que no he leído mucho sobre bases de datos, ni tampoco tengo mucha experiencia, la verdad. Lo hago como he dicho porque lo he visto hacer en otros proyectos, y, bueno, tampoco me he parado a pensar en si es la mejor forma o puede haber otras mejores.

Creo que no está mal identificar a cada campo con un prefijo, es decir, en lugar de:

Tabla: users

Campos: ID, login, name, password, etc.

Creo que algo como:

Tabla: users

Campos: user_id, user_login, user_name, user_password, etc.

Puede resultar curioso por varios motivos. 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.

Quizá ya menos se puedan dar casos como:

$login = $u->login;

En que acaso no queda muy claro qué es "$u", pero, reconozco también que un mejor identificador para la variable podría servir, y de hecho me encuentro a veces con cierta "redundancia", como pueda ser:

$login = $user->user_login;

Pero, no sé, ya digo... es como me he acostumbrado, aunque nunca es tarde para cambiar las formas, ahora mismo estoy trabajando así en el proyecto que estoy desarrollando ahora mismo. Quizás, es cierto, el tener varios cientos de pulsaciones por minuto ayude o haga que no se note tanto el asunto. :D

marcoszorrilla

24-11-2007, 11:11:54

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

24-11-2007, 16:50:59

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:

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.

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" :cool:

marcoszorrilla

24-11-2007, 19:30:24

Así es ContraVeneno.

Un Saludo.

Delphius

24-11-2007, 20:08:03

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" :cool:

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

25-11-2007, 03:33:46

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

Saludos

Delphius

25-11-2007, 03:52:20

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,

Al González

25-11-2007, 23:18:13

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

{ Poniendo en False el campo Vigente de UNA solicitud }
dtSolicitudVigente.Value := False;

{ ¡¡ ¿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. :)

Cannabis

26-11-2007, 08:25:19

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

marcoszorrilla

26-11-2007, 10:39:57

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

Un Saludo muy singular para esa gran pluralidad.

Lepe

26-11-2007, 10:49:32

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

Saludos

DJ VMan

11-01-2008, 15:57:15

Use el singular en vez del Plural.

La experiencia indica que (al menos en Inglés) el singular es más compatible con el modo en que comúnmente se usan los nombres de tablas y columnas en discusiones y documentación escrita del sistema.

a mi entender (y el de otros (http://www.ss64.com/orasyntax/naming.html) 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.

Fate

11-01-2008, 16:48:50

DJ VMan

11-01-2008, 17:09:15

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 (http://www.ss64.com/orasyntax/naming.html) 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)

caravena

11-01-2008, 17:44:51

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.

DJ VMan

11-01-2008, 17:54:46

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.

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.

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

Lepe

11-01-2008, 19:31:19

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

RONPABLO

11-09-2014, 10:00:32

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:

Perfiles
PerfilId
Nombre

Permisos
PermisoId
Nombre

PermisosPorPerfiles
PermisoPorPerfilId
PermisoId
PerfilId

Aunque yo prefiero algo así como:

Perfiles
Id
Nombre

Permisos
Id
Nombre

PermisosPorPerfiles
Id
PermisoId
PerfilId

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

roman

11-09-2014, 16:43:27

ContraVeneno

11-09-2014, 18:35:02

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:

From Facturas F
join clientes C on F.ClienteID = C.ID

Casimiro Notevi

11-09-2014, 19:12:59

Tabla en plural. Campos en singular.
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
select id, numero, fecha from tbVentas
select v.fecha, v.cliente, c.nombre
from tbventas v
inner join tbclientes c on c.id=v.idcliente

RONPABLO

11-09-2014, 19:27:08

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 [-] (http://www.clubdelphi.com/foros/#)select factura.* from ... where factura.clienteId = cliente.id

Si usamos el plural:

Código SQL [-] (http://www.clubdelphi.com/foros/#)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:

Select
Numero, Fecha, Valor, Descripcion
From Facturas
where Fecha between :f1 and :f2

El Resultado es un listado de varias facturas.

2. Cuando dice

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

roman

11-09-2014, 19:27:33

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

RONPABLO

11-09-2014, 20:28:27

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:

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:

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

roman

11-09-2014, 20:43:01

A ver, pregunta maliciosa:

¿Por qué no nombras tus tablas como fac, fdp, usu y así te evitas los alias?

:p

// Saludos

RONPABLO

11-09-2014, 20:53:16

A ver, pregunta maliciosa:

¿Por qué no nombras tus tablas como fac, fdp, usu y así te evitas los alias?

:p

// Saludos

:D

jajaja.... Bueno no lo hago porque los nombres trato que sean bien descriptivos (cosa que a ratos me arroja tablas con nombres muy largos), ahora se podrá decir que al poner el alias pierdo esa ´precisión que buscaba pero no ya que en la misma consulta tengo la respuesta a la duda:

From Usuarios u inner join Facturas on f.UsuarioId = u.id

Al ver la consulta identifico en ella misma que "u" (usu) es igual a Usuarios, mientras que si llamará las tablas así no tendría de donde aclarar

ecfisa

12-09-2014, 09:04:35

Hola.

Yo uso nombres de tablas en plural, nombres de columnas en singular y siempre un identificador único por tabla llamado 'ID'.

Pero no considero que sea mejor costumbre que usar nombres de tabla en singular, al fin y al cabo los sustantivos colectivos son singulares y definen a un grupo heterogéno.

En mi caso, la regla de uso me funciona como si fuese un mnemónico. Para mí, "Facturas" nunca será una columna ni "Remito" será una tabla, digamos que a esta altura es una convención conmigo mismo.

En cuanto a los alias los uso siempre que sean representativos y no ofusquen el código.

Saludos :)

roman

12-09-2014, 16:04:32

nombres de columnas en singular

Bueno, yo creo que aquí ya depende de cada columna. Por lo general, podría decirse que los nombres de columnas han de ser en singular dado que una tabla no debe contener columnas multivaluadas. No obstante hay casos justificados, por ejempo, una columna apellidos para los apellidos de una persona, en el caso en que no se requiera desglosar los dos.

En cuanto a lo demás concuerdo contigo en el sentido de que, a fin de cuentas, cada quien encuentra sus razones de porqué usa tal o cual nomenclatura. Lo importante es ser consistente consigo mismo o con el equipo en caso de un grupo de personas.

// Saludos

BlueSteel

12-09-2014, 21:28:18

Hola a Todos.... Tanto tiempo.. y aún con este gran Lio...

Singular o Plural... ese es el dilema ???

Con respecto a los Alias, casi nunca los utilizo..... por lo mismo que comentaba Roman... El tratar de acordarse que significa cierta letra en un codigo despues de varios años..... es un gran lio... :D:o:p

Saludos...

roman

12-09-2014, 21:48:33

Hola a Todos.... Tanto tiempo.. y aún con este gran Lio...

Y sí ... Mis jefes se están impacientando y aún no decido los nombres de ls tablas :eek:

:D

// Saludos

RONPABLO

13-09-2014, 03:33:39

A mi particularmente hilos como este me han servido mucho para definir mi forma de programar, tan simple que parece pero este hilo es muy util

marcoszorrilla

13-09-2014, 15:40:47

Yo utilizo el plural, por ejemplo Campo Autor perteneciente a la tabla Autores...

Un Saludo.

Al González

14-09-2014, 02:44:40

Han pasado siete años desde mi opinión sobre el tema y, aunque hoy lo explicaría con otras formas, mi convicción de usar los nombres de las tablas en singular se mantiene.

La clave está en que primero se definen las entidades (http://www.alegsa.com.ar/Dic/entidad.php). Las tablas, clases, formularios, botones y otros son elementos de sistema que pueden representar a esas entidades. Las entidades llevan sus nombres en singular (pluralizarlos no tendría sentido), y supone mayor consistencia propagar esos nombres a lo largo de la aplicación sin alterarlos gramaticalmente. Como bien sabemos, la consistencia dentro de cualquier desarrollo de software es sumamente importante.

Creo que es más fácil adherirse a esta idea una vez entendiendo que las tablas no son el inicio del diseño, sino meros elementos representativos de las entidades que previamente bosquejamos, como lo es también un formulario llamado fmAlumno, o una clase TAlumno. Entonces la programación se vuelve un poco más simple, al no involucrar en ella más complejidad de la necesaria (convengamos que una palabra en plural es por lo general una pizca más compleja que su versión en singular).

Saludos.

Al González.