Campos en Tablas

En teoría de conjuntos no se habla de claves, que yo sepa. :-)

Ok, mejor dicho, en teoría de Bases de datos que es la orientación única de
ustedes.

Es indiscutible que una clave es, entre otras cosas, un conjunto
de atributos. También en SQL Server.

Pero en su implementación de SQL Server, es "indiscutible" que hay un orden,
aunque a ti no te guste oírlo para no salirte de tu teórico modelo lógico.

Pero veo en tus reacciones que todavía no has entendido que una
clave no es lo mismo que un índice y un índice no es lo mismo que
una clave.

Pues para saber que Banco+Cheque me identifican con unicidad un registro de
mi tabla Cheques, tu preocupación porque supuestamente no lo entienda sale
sobrando. No sufras tanto por eso.

Y estoy empezando a creer que tampoco lo quieres
entender, solo quieres discutir.

Me gusta discutir pero no siempre. Contigo me divierto, te lo admito.
Dices tantas cosas teóricas desconociendo cómo se han implementado en SQL
Server que por eso te recomendé sanamente que mejor estarías en un foro de
teoría de bases de datos. Te insisto que no hay que saberlo todo cada vez.

Ahora en otra reacción hasta insinuas que no solo confundes índices
con claves, sino también campos con claves. (Que me imagine un
campo BancoCheque... uffff!)

Te puse el ejemplo BancoCheque a ver si lo entiendes de una vez por todas,
queriendo decir que en un campo único podrías, si tu quieres, juntar dos
cosas para formar un solo campo y usarlo de clave, para que no te confundas
con las compuestas. En mi país la cédula de identidad contiene 12 dígitos
pero los 3 primeros identifican la provincia del país. Hay miles de casos
de diseño de códigos compuestos en UN SOLO CAMPO. Claro... ya te veré
diciendo, eso es otra cosa, eso es la teoría tal y tal:) La
implementación es la implementación y para desarrollar sistemas en ella
tienes que basarte, y no en la teoría y sólo la teoría como tu pretendes.

>Qué 'pantalla de mi form'? De que estás hablando?
>Con 'su aplicación' me refería a 'aplicar' las reglas que está
>tratando de definir para determinar el nombre de los campos.

Pues aclara las cosas que aquí nadie es adivino.


No hace falta ser adivino. Solo leer y no imaginarse cosa:
"Sea cual sea tu elección, trata de que sea lo mas genérica posible
para después poder ser consecuente en su aplicación."

Aquí claramente en 'su aplicación', 'su' se refiere a 'tu elección'.
O sea que se está hablando de 'aplicar la elección'

Y tienes que darle y darle a eso, quisquilloso :) la terapia, la terapia...

Repito que ese término lo has sacado tu a relucir, por muchas
vueltas que le dés al asunto.
Y yo no le estoy quitando significado alguno al concepto de
clave primaria en SQL Server. Aunque tu no quieras entenderlo, le
estoy añadiendo mucho mas significado al entendimiento que tu
tienes del concepto.

Yo creo que quien ha demostrado, de nuevo, su desconocimiento de SQL Server
eres tú. Sigue con tu teoría que te va mejor. No le añades realmente más
significado a lo que yo le quise decir al OP cuando hablé de "ultimo campo"
de la clave compuesta, o índice compuesto como tú quieras llamarle. Más
bien yo creo que, aparte de para provocar, sólo has hecho confundir a todo
el que te lea y piense que Banco+Cheque es igual que Cheque+Banco como
"Primary Key" de una tabla de SQL Server.

Estoy tratando de comunicarme. Si necesito el concepto de conjunto
para aclarar algo, lo utilizo. Porque es un concepto tan básico que
muy probablemente estemos totalmente de acuerdo, aunque solo sea
intuitivamente, en cuanto a su significado. Eso evita confusiones
en la comunicación.

En vez de seguir pataleando, deberías estar agracecido de que
alguien tenga tanta paciencia explicándote cosas tan básicas.

Patalear es insistir, ya innecesariamente, en de no dar importancia a que
ciertamente la Primary Key de una tabla en sql server tiene un orden.
Parece que ni has visto cómo es que se define ( CONSTRAINT [PK_Tabla]
PRIMARY KEY CLUSTERED). Que lo confunda con un índice? si tú lo dices está
bien y podría admitirlo pero para SQL Server es una "primary key" y tiene un
orden.

No conociendome de nada (pero de nada!) y con bastantes prejuicios,
cualquier cosa que yo diga podría sorprenderte.

Prejuicios!!?? jajajaj. estaré hablando con una persona diferente ? o fue
que anduviste en reflexión por el Tibet y no has dicho nada?

No le dés mas vueltas. La cosa es bien simple:
una clave no es un índice y un índice no es una clave.

Está bien pero no terminas de entender lo que se te ha explicado y en qué
contexto hablé de último campo de la clave compuesta. Ahí se resume tu
problema y tu terquedad sólo para hacerle ver al foro que me ganaste la
discusión. Por eso te digo que tienes problemas de falta de humildad y ...
quien sabe cuáles otros :)

La cosa es que no puedes darte por vencido aunque te den todas las pruebas
del mundo. Eres bien terco.

Para SQL Server una "Primary Key" es un constraint basado en un conjunto
ORDENADO de columnas. Quien está dando vueltas desde hace rato eres tú y
vas a terminar mareado :)

Termino aquí pues no puedo cada vez estar explicándote las cosas :). A
otro que te ayude.

Cuídate mucho.

Resumiendo:

On 8 dec, 17:10, "Jose TH >>" wrote:

<...>

>Es indiscutible que una clave es, entre otras cosas, un conjunto
>de atributos. También en SQL Server.

Pero en su implementación de SQL Server, es "indiscutible" que hay un orden,

<...>

ciertamente la Primary Key de una tabla en sql server tiene un orden.
Parece que ni has visto cómo es que se define ( CONSTRAINT [PK_Tabla]
PRIMARY KEY CLUSTERED). Que lo confunda con un índice? si tú lo dices está
bien y podría admitirlo pero para SQL Server es una "primary key" y tiene un
orden.

<...>

Para SQL Server una "Primary Key" es un constraint basado en un conjunto
ORDENADO de columnas.

Y yo soy terco! :o

:)

Hola Carlos,

On 8 dic, 18:46, "Carlos M. Calvelo" wrote:

> >Es indiscutible que una clave es, entre otras cosas, un conjunto
> >de atributos. También en SQL Server.

> Pero en su implementación de SQL Server, es "indiscutible" que hay un orden,

> ciertamente la Primary Key de una tabla en sql server tiene un orden.
> Parece que ni has visto cómo es que se define ( CONSTRAINT [PK_Tabla]
> PRIMARY KEY CLUSTERED).   Que lo confunda con un índice? si tú lo dices está
> bien y podría admitirlo pero para SQL Server es una "primary key" y tiene un
> orden.

> Para SQL Server una "Primary Key" es un constraint basado en un conjunto
> ORDENADO de columnas.

Y yo soy terco! :o

Veo que no me equivoqué al filtrarle. 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. A ver en donde está la diferencia entre:
no puede haber dos filas con el mismo tipo y cheque y no puede haber
dos filas con el mismo cheque y tipo.

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.

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


Saludos

Veo que no me equivoqué al filtrarle.

Tú no me has filtrado nada. Sé que lees todos mis mensajes.

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.

Debo entenderlo bien, como también entiendo lo que es la 1era Forma Normal,
que tú todavía no entiendes como demostraste en el hilo "Problema con
claves". Allí revísate el link que te puse de tu querida Wiki, para que
entiendas lo que es la 1era forma normal y no pases verguenza tratando de
discutir sobre el tema. Fui a la Wiki adrede pues sé que te encanta. :)

A ver en donde está la diferencia entre:
no puede haber dos filas con el mismo tipo y cheque y no puede haber
dos filas con el mismo cheque y tipo.

Pues que en la vida real los numeros de cheque se encuentra dentro del
folder del tipo o del banco. Entiendes??? mmmm.. no creo.

Cuando pones PRIMARY KEY CLUSTERED lo de CLUSTERED ser refiere al
orden de la tabla física y no es parte de la clave.

Bueno, ahí Carlos demostró que por lo menos razona mejor que tú. Ni has
seguido la discusión y ni entiendes el contexto de lo que puse. Que
cerebrito eres!

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

Tu mente hace tiempo que está no solo sucia sino llena de vacío existencial,
aunque parezca paradójico. Vete a estudiar las formas normales. Empieza por
la primera y después te dedicaré tiempo. :)

Y yo soy terco! :o
:)

Quizás seamos dos. En fin, no es ningún pecado :)