Campos en Tablas

On 7 dec, 14:42, "Jose TH" <>>> wrote:

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

Y seguro en su aplicación "Tipo+Cheque" será lo mismo que "Cheque+Tipo"!
Seguro que en la pantalla de tu form lo lees indistintamente ya que no hay
un "ultimo campo" en una clave primaria, o "índice primario", cosa inventada
por ti. La implementación la implementación

A ver que te lo explico otra vez.
La clave {Tipo, Cheque} es la misma que {Cheque, Tipo}. No se
pueden diferenciar, son la misma. Por eso no hay tal 'última'
columna. Es lo mismo que decir que los conjuntos {a,b} y {b,a}
son el mismo. No hay orden, no hay tal 'último' elemento.

El índice "Tipo+Cheque" no es le mismo que "Cheque+Tipo" y si la
clave {Tipo, Cheque} se realiza con el indice "Tipo+Cheque" sigue
siendo la misma clave que si se realiza con el índice "Cheque+Tipo"

Básico!

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.

Y yo nunca he utilizado el término "índice primario". Si alguien
se ha inventado eso.., habrás sido tu.

Utilizar conceptos que solo tienen significado a nivel físico para
tomar decisiones sobre el modelo lógico no es un 'mínimo error'.
Es bastante grave y precisamente lo que tu estás haciendo.

Es grave decidir que en una aplicación no será lo mismo "Tipo+Cheque" o más
realista "Banco+Cheque" que en sentido inverso ?
Si no contemplas eso en el diseño de tu aplicación deberías ir a estudiar de
nuevo SQL Sever o diseño de sistemas. No sé en qué mundo vives para
suponer que en la vida real el diseño sea estrictamente independiente de la
implementación. Tu mundo lógico sólo existe en tu mente ortodoxa.
Te repito que te queda mejor tu teoría superficial en un foro de teoría de
bases de datos. No de SQL Server ni de desarrollo de aplicaciones.

Habrás desarrollado aplicaciones realmente ?... es de dudar después de leer
tu ortodoxa teoría sobre la independecia lógica de la semántica o la
decisión de definir una clave (o índice cuaternario, como quieras:).

Banco+Cheque = Cheque+Banco!!! eso es realmente una tontería. Si te
complica mucho y no te enteras todavía, imagínalo como si fuese un solo
campo BancoCheque y... piénsalo de nuevo, ya te veré diciendo lo contrario a
lo que has dicho, lo cual es tu costumbre :)

El problema no es si yo he oído hablar o no de análisis.

Pues por supuesto que es un problema grave, porque antes del diseño viene el
análisis (en el mundo real) para enterarse de qué se trata el asunto y
entender por ejemplo que encontrarás un cheque "dentro" del folder del tipo
(o del banco) antes de encontrar su numeración.
Dile a un contador en el mundo real que el par {Banco,Cheque} no deba ser un
par ordenado y seguramente que el contador te hará recordar a tus familiares
más cercanos :)

El problema
es que tu no sabes diferenciar entre diseño físico y diseño lógico.
Por eso utilizas cualidades del primero (índice, orden de columnas
en un índice) para tomar decisiones a nivel lógico (nombre de
columna, clave).

El problema es que "tu" diseño lógico sólo existe en los libros de teoría de
bases de datos. Te repito que este es un foro de SQL Server.

La clave {Tipo, Cheque} es la misma que {Cheque, Tipo}. No se
pueden diferenciar, son la misma. Por eso no hay tal 'última'
columna. Es lo mismo que decir que los conjuntos {a,b} y {b,a}
son el mismo. No hay orden, no hay tal 'último' elemento.

Claro que sí. En teoría de conjuntos. Este es un foro de SQL Server.
"Básico! ".

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.

Y yo nunca he utilizado el término "índice primario". Si alguien
se ha inventado eso.., habrás sido tu.

No lo habrás dicho exactamente así pero se deduce de tu insistencia en
quitarle el significado que tiene "Primary Key" en SQL Server. Y este es un
foro de
SQL Server, no de teoría de conjuntos, repito.


Nota: Tengo que decir que la verdad me sorprende lo "decente" que estás! No
has hecho ningún insulto... ya vas mejorando :)) realmente se puede debatir
sin provocaciones y ofensas innecesarias como dijo otro compañero. Espero
que sigas así aunque conociéndote dudo que tu orgullo te conserve la cordura
mucho tiempo :)
Saludos

On 7 dec, 17:49, "Jose TH" <>>> wrote:

>La clave {Tipo, Cheque} es la misma que {Cheque, Tipo}. No se
>pueden diferenciar, son la misma. Por eso no hay tal 'última'
>columna. Es lo mismo que decir que los conjuntos {a,b} y {b,a}
>son el mismo. No hay orden, no hay tal 'último' elemento.

Claro que sí. En teoría de conjuntos. Este es un foro de SQL Server.
"Básico! ".

En teoría de conjuntos no se habla de claves, que yo sepa. :-)
Es indiscutible que una clave es, entre otras cosas, un conjunto
de atributos. También en SQL Server.

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. Y estoy empezando a creer que tampoco lo quieres
entender, solo quieres discutir.

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

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

"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 yo nunca he utilizado el término "índice primario". Si alguien
>se ha inventado eso.., habrás sido tu.

No lo habrás dicho exactamente así pero se deduce de tu insistencia en
quitarle el significado que tiene "Primary Key" en SQL Server.

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.

Y este es un
foro de
SQL Server, no de teoría de conjuntos, repito.

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.

Nota: Tengo que decir que la verdad me sorprende lo "decente" que estás! No
has hecho ningún insulto... ya vas mejorando :)) realmente se puede debatir
sin provocaciones y ofensas innecesarias como dijo otro compañero. Espero
que sigas así aunque conociéndote dudo que tu orgullo te conserve la cordura
mucho tiempo :)

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

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