Campos en Tablas

Preguntas:
1.- Es correcto la forma de nombra el Id de la tabla ?? es decir Id_
[Nombre_Identificatorio]

Puede haber literatura que recomienden sobre eso e influye el gusto personal
pero yo prefiero economizarme el "Id_" o el "Num_". Generalmente yo nombro
el campo de la PK (o el último campo, para claves compuestas) justo con el
mismo nombre de la entidad (en singular). Ej. "Cliente", "Proveedor", etc.

2.- Como veran en cada tabla tengo una fecha en algun momento se
realizara un Select que equipare fechas (es un ejemplo) es correcto
que en el Where tenga que poner: A.FechaIngreso=B.FechaVenta, según
FN deberia ambas llamarse igual. en este caso es logico que en la
tabla Ventas el campo fecha se llame FechaIngreso

Si ambas fechas significan lo mismo podrían llamarse igual, aunque en ese
ejemplo no parecen significar lo mismo. Habría que ver cada caso particular,
pero si se trata de una tabla de "Ventas" o en general de cualquier tipo de
transacción, yo le pondría simplemente "Fecha". El sufijo "Venta" es
redundante e innecesario, en ese caso. No así con el sufijo "Ingreso" para
el campo FechaIngreso de la tabla de clientes, donde creo que tiene más
sentido.
Si hay otras fechas en la tupla, también procede agregar otra palabra de
sufijo cualificador.

3.- En algun partte lei que en la descripcion de lso campos se deberia
poner algun sufijo, ejmplo gls_Descripcion (donde podria encontrar
algo al respecto ? ojala en español)

Eso sería "pre"fijo. De nuevo te digo que puede haber mucha literatura en
GOOGLE al respecto y que es cuestión de gusto personal pero mi opinión, sin
pretensiones, es poner el nombre justo que te dé lo que significa el campo.
Con palabras del lenguaje natural. Evitar, siempre que sea posible,
abreviaturas, sufijos o prefijos innecesarios. Poner los necesarios sólo
para evitar confusiones.

Hola Penta,

El Wed, 3 Dec 2008 11:34:27 -0800 (PST), Penta escribió:

1.- Es correcto la forma de nombra el Id de la tabla ?? es decir Id_
[Nombre_Identificatorio]

No es correcto ni incorrecto, pero no le veo sentido. ¿Para que sirve
ponerle Id_ delante?

Si tienes un nombre identificativo pues lo usas y listo.

2.- Como veran en cada tabla tengo una fecha en algun momento se
realizara un Select que equipare fechas (es un ejemplo) es correcto
que en el Where tenga que poner: A.FechaIngreso=B.FechaVenta, según
FN deberia ambas llamarse igual.

¿Quien es FN?

A la de cliente yo le suelo llamar FechaAlta y a la de ventas Fecha.

3.- En algun partte lei que en la descripcion de lso campos se deberia
poner algun sufijo, ejmplo gls_Descripcion (donde podria encontrar
algo al respecto ? ojala en español)

Eso es un prefijo no un sufijo, pero me parece una mala idea. No conozco a
nadie que recomiende eso.


Saludos
Alfredo

"Penta" escribió en el mensaje
news:
Estimados.
tengo tabla Clientes, Proveedores, Ventas.
Entre otros campos necesito aclarar:

Cliente
Id_Cliente
Descripcion
FechaIngreso

Ventas
Id_Numero
Id_Cliente
FechaVenta

Preguntas:
1.- Es correcto la forma de nombra el Id de la tabla ?? es decir Id_
[Nombre_Identificatorio]
2.- Como veran en cada tabla tengo una fecha en algun momento se
realizara un Select que equipare fechas (es un ejemplo) es correcto
que en el Where tenga que poner: A.FechaIngreso=B.FechaVenta, según
FN deberia ambas llamarse igual. en este caso es logico que en la
tabla Ventas el campo fecha se llame FechaIngreso
3.- En algun partte lei que en la descripcion de lso campos se deberia
poner algun sufijo, ejmplo gls_Descripcion (donde podria encontrar
algo al respecto ? ojala en español)

-

Hola, Penta:

Normalmente las bases de datos se diseñan para que los programas trabajen
con ellas.

Y los programas se diseñan para utilizar la menor cantidad posible de
componentes funcionales en la mayor cantidad de puntos de función.

Una de las maneras de lograr esta "economía de código" es el uso de
procedimientos parametrizados. Y estos procedimientos son tanto más simples
cuanto más homogénea sea la estructura de los objetos sobre los cuales
operan. Si comparas el registro de un cliente con el de un proveedor, verás
que tienen mucho en común: ambos están identificados por un CODIGO, ambos
tienen un NOMBRE, una DIRECCION, un TELEFONO, unas CONDICIONES estándar, un
SALDO (de signo contrario normalmente, pero eso es un detalle menor). Si el
nombre de las columnas en cada tabla es el nombre genérico de la variable
cuya representación se almacena en la columna, podrías tener una rutina de
actualización común que sólamente dependiera del nombre de la tabla. Lo
mismo con reportes o consultas.

Y más o menos lo mismo pasa con los documentos. Una factura de compra, o una
de venta, o una nota de crédito tienen una Fecha. Si escribes FechaVenta,
FechaCompra, FechaEmision lo que estás haciendo es utilizando diferentes
nombres locales para la misma cosa. Si utilizas un nombre común (yo lo llamo
FechaTransaccion) igualmente podrás escribir código que podrás aprovechar en
diferentes tipos de documentos.

El asunto de los prefijos es otra cosa. Nadie espera que un Saldo sea una
variable VARCHAR. Todo el mundo sabe que los saldos son MONEY. Y las fechas
son DATETIME (o SMALLDATETIME, al gusto del consumidor), y los nombres son
VARCHAR o NVARCHAR. Los prefijos -introducidos por MS a instancias de
Charles Simonyi como una manera de estar seguros de que los desarrolladores
estuvieran conscientes del tipo de las variables con las que operaban-
pueden tener algún tipo de sentido cuando se está escribiendo código (aunque
si ves los estandares de nomenclatura propuestos para los lenguajes .NET,
notarás que la notación húngara ha caido en desuso), pero me parecen puro
desperdicio si lo aplicas a los nombres de las columnas. He visto gente que
precede los nombre de las tablas con "tbl" (es decir, tblClientes en vez de
Clientes). Igual puede servir para asegurarse de que uno está consciente de
que está trabajando contra una tabla en vez de contra una vista (cuyos
nombre preceden con "vst" o "vw"), pero nuevamente es traicionar el
principio de "encapsulamiento": la diferencia entre una tabla y una vista es
significativa para el DBA (que usa herramientas que muestran unas en una
parte y otras en otra) pero debería ser totalmente irrelvante para el
programador, que simplemente las llama por el nombre de las entidades que
representan.

Pero, por supuesto, todo es cuestión de gustos.


Salud!

Estimados.
Me hes muy grato como siempre leer sus sabias respuestas.

Y en lo unico que al "parecer" aun no cambiare sera la forma de llamar
al id de la PK, ejemplo IdCliente

Seguire con notacion Hungara, con los demas campos FechaTransaccion

Estimados, GRACIAS TOTALES !!!!

PS. FN me referia a Forma Normal

Penta.

Hola Penta,

El Fri, 5 Dec 2008 05:36:46 -0800 (PST), Penta escribió:

Seguire con notacion Hungara, con los demas campos FechaTransaccion

No entiendo esto. La notación húngara consiste en ponerle un prefijo a los
nombres de las variables y es algo que ya casi nadie usa ni aconseja. Y
menos con lenguajes que no sean C++.

PS. FN me referia a Forma Normal

Las formas normales son 6 (aunque la primera no sirve para nada) y no
tienen nada que ver con los nombres de los atributos de las tablas.



Saludos