Campos en Tablas

03/12/2008 - 20:34 por Penta | Informe spam
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)

Atte.
Penta.

Preguntas similare

Leer las respuestas

#41 Alfredo Novoa
09/12/2008 - 02:59 | Informe spam
El Mon, 8 Dec 2008 16:01:48 -0800 (PST), Carlos M. Calvelo escribió:

Y yo reaccionando.. ya no te funciona. Me vas a tener que meterme
a mi también en el filtro. :-)



Por esta vez te lo perdono :-)

Por cierto, van muy bien las reglas PLONK del lector 40tude Dialog que me
recomendaste. Tengo que acabar de instalarlo en todos mis ordenadores.

Y yo tengo una pequeña desconfianza de que en este caso no es
SQL Server el que lleva la mayor parte de la culpa en eso. Las
aplicaciones no consultan la base de datos especificando índices.



Ya, pero en este caso no estamos hablando de consultas, y la sintaxis para
la definicion de claves primarias de SQL Server es bastante chapuza. Como
mínimo que hubiesen metido lo del CLUSTERED en el WITH junto con lo del
PAD_INDEX y demás.


Saludos
Alfredo
Respuesta Responder a este mensaje
#42 Jose TH
09/12/2008 - 12:46 | Informe spam
Fuera bueno que le expliques entonces al foro como se define una "CLAVE" en
SQL Server a ver si dejas de




"Carlos M. Calvelo" escribió en el mensaje
news:
On 9 dec, 01:32, "Jose TH" <>>> wrote:

> Cuando pones PRIMARY KEY CLUSTERED lo de CLUSTERED ser refiere al
> orden de la tabla física y no es parte de la clave. Igual que lo de
> PAD_INDEX = OFF tampoco es parte de la clave.
>Bueno... para que entrar en más detalles?!

Pensaba que tú lo entendías pero ya veo que tu pensamiento también anda de
vacaciones. No lees donde dice "PRIMARY KEY"? De qué crees que
estábamos
discutiendo?



Si hombre, claro que veo donde pone PRIMARY KEY. Y también veo donde
pone CLUSTERED. Pero es que ya estoy cansado de repetir que claves
no son índices y índices no son claves. Y CLUSTERED es una propiedad
del índice, no de la clave.

Ahh! Que paciencia hay que tener
Respuesta Responder a este mensaje
#43 Jose TH
09/12/2008 - 12:52 | Informe spam
Pues olvidense de "Indices" y del Primary Key Clustered, háganse una "Clave
unique", es decir un simple Constraint y luego hagan una relación foránea
desde otra tabla. Traten luego de insertar datos para la clave compuesta.
Inviertan el orden. Si les funciona, pues el orden no es importante. Si no
les funciona, pues termiten de admitir que lo que dicen ustedes no es
cierto. No quieran confundir a la gente.


"Alfredo Novoa" escribió en el mensaje
news:lva5p9dswth0$.1m3dnb966tgih$
El Mon, 8 Dec 2008 16:01:48 -0800 (PST), Carlos M. Calvelo escribió:

Y yo reaccionando.. ya no te funciona. Me vas a tener que meterme
a mi también en el filtro. :-)



Por esta vez te lo perdono :-)

Por cierto, van muy bien las reglas PLONK del lector 40tude Dialog que me
recomendaste. Tengo que acabar de instalarlo en todos mis ordenadores.

Y yo tengo una pequeña desconfianza de que en este caso no es
SQL Server el que lleva la mayor parte de la culpa en eso. Las
aplicaciones no consultan la base de datos especificando índices.



Ya, pero en este caso no estamos hablando de consultas, y la sintaxis para
la definicion de claves primarias de SQL Server es bastante chapuza. Como
mínimo que hubiesen metido lo del CLUSTERED en el WITH junto con lo del
PAD_INDEX y demás.


Saludos
Alfredo
Respuesta Responder a este mensaje
#44 Jose TH
09/12/2008 - 12:53 | Informe spam
Además:

Pues olvidense de "Indices" y del Primary Key Clustered, háganse una "Clave
unique", es decir un simple Constraint y luego hagan una relación foránea
desde otra tabla. Traten luego de insertar datos para la clave compuesta.
Inviertan el orden de los datos en la tabla de la clave foránea. Si les
funciona, pues el orden no es importante. Si no les funciona, pues termiten
de admitir que lo que dicen ustedes no es cierto. No quieran confundir a la
gente.



"Carlos M. Calvelo" escribió en el mensaje
news:
On 9 dec, 01:32, "Jose TH" <>>> wrote:

> Cuando pones PRIMARY KEY CLUSTERED lo de CLUSTERED ser refiere al
> orden de la tabla física y no es parte de la clave. Igual que lo de
> PAD_INDEX = OFF tampoco es parte de la clave.
>Bueno... para que entrar en más detalles?!

Pensaba que tú lo entendías pero ya veo que tu pensamiento también anda de
vacaciones. No lees donde dice "PRIMARY KEY"? De qué crees que
estábamos
discutiendo?



Si hombre, claro que veo donde pone PRIMARY KEY. Y también veo donde
pone CLUSTERED. Pero es que ya estoy cansado de repetir que claves
no son índices y índices no son claves. Y CLUSTERED es una propiedad
del índice, no de la clave.

Ahh! Que paciencia hay que tener
Respuesta Responder a este mensaje
#45 Jose TH
09/12/2008 - 13:23 | Informe spam
Sí, sí.. ya me lo han dicho que es una pérdida de tiempo de mi parte pero
quien sabe, si es parte de mi misión ser un "anti-troll" :)))



"Sebastián Gómez" escribió en el mensaje
news:
Hi, Jose TH
Jejeje... le has dado duro a los troll ! Pero aun asi por que pierdes tu
tiempo en eso ya que esos dos nunca van a perder una discusion porque
ponen al reves todo lo que han dicho antes para no perder, donde dice digo
dijo diego, eso parece como un problema de salud mental o de doble
personalidad, algun medico que lo diga, y lo raro es que haya dos justo
con el mismo style. ...jejej

Ya me pasó en otro thread donde por suerte me advirtieron en un mensaje
privado que se trataba de dos conocidos troll's por cierto bastante
irrespetuosos y mal educados.
Saludos y take it easy!

<Jose TH >>> escribió en el mensaje
news:

Y yo reaccionando.. ya no te funciona. Me vas a tener que meterme
a mi también en el filtro. :-)



El no me ha filtrado nada. En eso se porta como un niño malcriado,
igual que tú. Parecen hermanos.
No se dan cuenta que mientras más hablan queriendo provocar sólo hacen
meter la pata más y más.

Está claro que nunca lo
entenderá por que no sabe lo que es una clave ni la diferencia entre
el nivel físico y el lógico.



En una reacción anterior se burló de la mención que he hecho otras
veces de la independencia lógica de datos lamandolo 'independecia
lógica de la semántica'.
Y ahora, efectivamente, resulta que de indendencia física de datos
(en mi opinión todavía mucho mas básico) pues tampoco tiene ni idea.




Es que yo pasé hace tiempo de esa teoría vana de los años 80's de ustedes
a conocer implementaciones como SQL Server donde implementar los diseños.
No me he quedado soñando con teoría de conjuntos y de Bases de Datos como
ustedes.
El ejemplo más reciente: Alfredo Novoa demuestra que ni conoce la primera
forma normal. Se ve claro en otro hilo. Debería darle verguenza al
famoso "maestrico" como le han llamado.


Cuando pones PRIMARY KEY CLUSTERED lo de CLUSTERED ser refiere al
orden de la tabla física y no es parte de la clave. Igual que lo de
PAD_INDEX = OFF tampoco es parte de la clave.



Bueno... para que entrar en más detalles?!



Pensaba que tú lo entendías pero ya veo que tu pensamiento también anda
de vacaciones. No lees donde dice "PRIMARY KEY"? De qué crees que
estábamos discutiendo? ahora quieres venir a confundir de nuevo sacando
cosas de contexto igual que tu querido consorte Alfredo Novoa, el que
confunde la formas normales sin conocer siquiera la primera.


Y después dicen que no es peligroso que un lenguaje de programación
sea sucio. Si no tienes cuidado te ensucia la mente.




Y yo tengo una pequeña desconfianza de que en este caso no es
SQL Server el que lleva la mayor parte de la culpa en eso. Las
aplicaciones no consultan la base de datos especificando índices.
Pero por ahí hay algún que otro lenguaje con 'procesador de
archivos' que sí lo hace. (Solo una idea que tengo)




Como todos los programadores que tenemos tiempo en esto pues claro que
trabajé hace tiempo con sistemas de archivos y no de bases de datos. Pero
hace tiempo que trabajo con Oracle y SQL Server en aplicaciones
financieras reales, por cierto usadas en varios países, lo digo sólo
porque siempre advierto como ustedes quieren burlarse de los pocos
conocimientos que puedan tener los demás. Sin embargo tú pareces que
todavía no te enteras que SQL Server, una implementación específica de tu
apreciada teoría, ya existe desde hace tiempo, descendiendo a un nivel
más realista que tu ortodoxa teoría.

La verdad que después de ver algunos mensajes algo "lights" tuyos vuelvo
a descubrir las frustraciones que tratas de ocultar ahora, aparentando lo
que no eres. Es claro que estás haciendo un esfuerzo sobre humano para
tragarte tu orgullo y no empezar a insultar ya que se te acabaron hace
rato los argumentos para defender todas las tonterías que has dicho que
hasta has traído al llamado "maestrico" Alfredo Novoa para que te ayude.
Son dos niños malcriados que hacen el ridículo. :-||| Salvo por los
insultos, hasta ahora, parece que no te hizo mucho la terapia :)

Como les han preguntado otros, han desarrollado aplicaciones realmente
ustedes ? Han trabajado en el mundo real ?
A ver muéstrenle al foro alguna aplicación desarrollada por ustedes.
A ver, dile al maestrico Alfredo que le muestre al foro el sistema de
manejo de bases de datos que él lleva años "desarrollando" ya que sql
server "no sirve" según sus propias palabras.








Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida