FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
[Tablas] ¿ Plural o singular ?
Estamos teniendo una discusión teórica con mis compañeros de trabajo.
Los nombre de las tablas deberian ir en plural o en singular ??? O sea Empleado o Empleados ??? Cliente o Clientes ?? La discusión solo es por el nombre de las tablas, no de clases u otra cosa. Yo estoy convencido que debe ir en plural porque se hace referencia a varios Clientes (en el caso de clientes, obvio). Que opinan ustedes ?? |
#2
|
||||
|
||||
Yo opino lo mismo que vos, pero definitivamente es una politica de desarrollo que se debe definir en grupo y todos estar de acuerdo en adoptar sea cual sea la conclusión .
__________________
Lecciones de mi Madre. Tema: modificación del comportamiento, "Pará de actuar como tu padre!" http://www.purodelphi.com/ http://www.nosolodelphi.com/ |
#3
|
|||
|
|||
Si totalmente de acuerdo, eso lo tenemos definido ya, por eso aclaré que era una discusión teórica. :P
|
#4
|
||||
|
||||
desde mi humilde perspectiva debe ser plural.
el princio es sencillo, la empresa tiene UN cliente o tiene CLIENTES? suerte. Un cliente tiene Un estado o puede tener uno entre varios ESTADOS?
__________________
Conoce mi blog http://www.edgartec.com |
#5
|
||||
|
||||
mmm... plural... yo diría que es obvio el porque, pero en fin... yo defino los nombres de las tablas en plural.
__________________
|
#6
|
||||
|
||||
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: Código:
tabla Cliente: idcliente autoinc, Cliente varchar 100 tabla Factura: idFactura autoinc Factura char(15) /* el número de factura */ idcliente (clave ajena) PD: Me ha gustado mucho este tema, fijaté . Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. Última edición por Lepe fecha: 23-11-2007 a las 22:51:38. |
#7
|
||||
|
||||
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. |
#8
|
|||
|
|||
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 |
#9
|
|||
|
|||
Cita:
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 )
__________________
- Si tienes un problema que tiene solución ¿porque te preocupas? - Si tienes un problema que no tiene solución ¿porque te preocupas? |
#10
|
|||
|
|||
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. |
#11
|
|||
|
|||
Cita:
Cita:
Cita:
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? |
#12
|
||||
|
||||
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. |
|
|
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 |
|