Indice unico con filtro

Sobre el primer punto fue un error pues lo que quise poner fue lo mismo que
expone Ricardo Passians pero se me cruzaron los cables.

Verdad que se puede hacer asi realmente ?



"Alejandro Mesa" wrote in message
news:

Pedro,

Interesantes tus preguntas. Veamos que pasa con ejemplos practicos.

1) Si uno en vez de poner "then 0" pone la misma columna en cuestion (ej:
col3 as case when col1 in (1, 3) then col1 else pk end ), no se obtendria
la
misma utilidad? E incluso la restriccion podria dejarse para solo la
columna calculada col3 ej: constraint uq_t1_coll3 unique (col3). Es asi
o
lo he interpretado mal ?

Como la condicion de la columna [col1] involucra mas de un valor, entonces
podemos correr el riesgo de tener esta combinacion:

col1 = 1, col2 = 1, col3 = 1
col1 = 3, col2 = 1, col3 = 3

como puedes ver, el valor de [col2] se repite, sin embargo el valor de
[col3] son diferentes y por lo tanto la restriccion de unicidad por ambas
columnas no falla. Si usamos cualquier constante, digamos 0, entonces
quedaria:

col1 = 1, col2 = 1, col3 = 0
col1 = 3, col2 = 1, col3 = 0

y aqui la restriccion de unicidad por ([col2], [col3]) dara error.

2) En el caso de que la pk sea multicolumnas y sus columnas sean
alfanumericas, ciertamente se podria usar el mismo criterio concatenando
la
pk en
una sola expresion ? ej. case when col1 in (1,3) then '0' else
pkcol1+pkcol2 end.

La concatenacion puede dar como resultado valores iguales para diferentes
combinaciones.

pk1 = 'micro', pk2 = 'soft', col1 = 2, col2 = 1, col3 = 'microsoft'
pk1 = 'micr', pk2 = 'osoft', col1 = 4, col2 = 1, col3 = 'microsoft'

a pesar de que la restriccion de clave primaria es unica a nivel de
multi-columnas, la concatenacion no lo es.y por tanto ([col2], [col3]) no
lo
es apesar de que [col1] no es 1 o 3.


AMB


"Pedro Echavarria" wrote:

>
> ambien puedes crear una columna calculada y usar esta junto col2 para
> definir una restriccion de unicidad. Este metodo funciona si tienes una
> clave
> primaria que no sea multi-columnas. Supongamos que tienes:
>

Leyendo esa interesante idea me surgen estas preguntas, amigo Alejandro:

1) Si uno en vez de poner "then 0" pone la misma columna en cuestion (ej:
col3 as case when col1 in (1, 3) then col1 else pk end ), no se obtendria
la
misma utilidad? E incluso la restriccion podria dejarse para solo la
columna calculada col3 ej: constraint uq_t1_coll3 unique (col3). Es asi
o
lo he interpretado mal ?

2) En el caso de que la pk sea multicolumnas y sus columnas sean
alfanumericas, ciertamente se podria usar el mismo criterio concatenando
la
pk en
una sola expresion ? ej. case when col1 in (1,3) then '0' else
pkcol1+pkcol2 end.

Bueno, alguien mas tiene la respuesta?





"Pedro Echavarria" wrote in message
news:

Sobre el primer punto fue un error pues lo que quise poner fue lo mismo
que expone Ricardo Passians pero se me cruzaron los cables.

Verdad que se puede hacer asi realmente ?



"Alejandro Mesa" wrote in
message news:

Pedro,

Interesantes tus preguntas. Veamos que pasa con ejemplos practicos.

1) Si uno en vez de poner "then 0" pone la misma columna en cuestion
(ej:
col3 as case when col1 in (1, 3) then col1 else pk end ), no se
obtendria la
misma utilidad? E incluso la restriccion podria dejarse para solo la
columna calculada col3 ej: constraint uq_t1_coll3 unique (col3). Es asi
o
lo he interpretado mal ?

Como la condicion de la columna [col1] involucra mas de un valor,
entonces
podemos correr el riesgo de tener esta combinacion:

col1 = 1, col2 = 1, col3 = 1
col1 = 3, col2 = 1, col3 = 3

como puedes ver, el valor de [col2] se repite, sin embargo el valor de
[col3] son diferentes y por lo tanto la restriccion de unicidad por ambas
columnas no falla. Si usamos cualquier constante, digamos 0, entonces
quedaria:

col1 = 1, col2 = 1, col3 = 0
col1 = 3, col2 = 1, col3 = 0

y aqui la restriccion de unicidad por ([col2], [col3]) dara error.

2) En el caso de que la pk sea multicolumnas y sus columnas sean
alfanumericas, ciertamente se podria usar el mismo criterio concatenando
la
pk en
una sola expresion ? ej. case when col1 in (1,3) then '0' else
pkcol1+pkcol2 end.

La concatenacion puede dar como resultado valores iguales para diferentes
combinaciones.

pk1 = 'micro', pk2 = 'soft', col1 = 2, col2 = 1, col3 = 'microsoft'
pk1 = 'micr', pk2 = 'osoft', col1 = 4, col2 = 1, col3 = 'microsoft'

a pesar de que la restriccion de clave primaria es unica a nivel de
multi-columnas, la concatenacion no lo es.y por tanto ([col2], [col3]) no
lo
es apesar de que [col1] no es 1 o 3.


AMB


"Pedro Echavarria" wrote:

>
> ambien puedes crear una columna calculada y usar esta junto col2 para
> definir una restriccion de unicidad. Este metodo funciona si tienes
> una
> clave
> primaria que no sea multi-columnas. Supongamos que tienes:
>

Leyendo esa interesante idea me surgen estas preguntas, amigo Alejandro:

1) Si uno en vez de poner "then 0" pone la misma columna en cuestion
(ej:
col3 as case when col1 in (1, 3) then col1 else pk end ), no se
obtendria la
misma utilidad? E incluso la restriccion podria dejarse para solo la
columna calculada col3 ej: constraint uq_t1_coll3 unique (col3). Es asi
o
lo he interpretado mal ?

2) En el caso de que la pk sea multicolumnas y sus columnas sean
alfanumericas, ciertamente se podria usar el mismo criterio concatenando
la
pk en
una sola expresion ? ej. case when col1 in (1,3) then '0' else
pkcol1+pkcol2 end.

Pedro,

>>> 1) Si uno en vez de poner "then 0" pone la misma columna en cuestion

Si la columna [col2] no acepta null, entonces si puede ser una solucion.
Pero si esta acepta NULL y ademas queremos aplicar la restriccion de unicidad
solo para valores no nulos, entonces no creo que sea factible hacerlo de esa
forma.

>>> 2) En el caso de que la pk sea multicolumnas y sus columnas sean
>>> alfanumericas, ciertamente se podria usar el mismo criterio concatenando
>>> la
>>> pk en

?Puede que funciones, pero si la cosa se va a complicar demasiado, entonces
me voy por la alternativa de usar una vista indexada.


Saludos,

AMB

"Pedro Echavarria" wrote:

Bueno, alguien mas tiene la respuesta?





"Pedro Echavarria" wrote in message
news:
> Sobre el primer punto fue un error pues lo que quise poner fue lo mismo
> que expone Ricardo Passians pero se me cruzaron los cables.
>
> Verdad que se puede hacer asi realmente ?
>
>
>
> "Alejandro Mesa" wrote in
> message news:
>> Pedro,
>>
>> Interesantes tus preguntas. Veamos que pasa con ejemplos practicos.
>>
>>> 1) Si uno en vez de poner "then 0" pone la misma columna en cuestion
>>> (ej:
>>> col3 as case when col1 in (1, 3) then col1 else pk end ), no se
>>> obtendria la
>>> misma utilidad? E incluso la restriccion podria dejarse para solo la
>>> columna calculada col3 ej: constraint uq_t1_coll3 unique (col3). Es asi
>>> o
>>> lo he interpretado mal ?
>>
>> Como la condicion de la columna [col1] involucra mas de un valor,
>> entonces
>> podemos correr el riesgo de tener esta combinacion:
>>
>> col1 = 1, col2 = 1, col3 = 1
>> col1 = 3, col2 = 1, col3 = 3
>>
>> como puedes ver, el valor de [col2] se repite, sin embargo el valor de
>> [col3] son diferentes y por lo tanto la restriccion de unicidad por ambas
>> columnas no falla. Si usamos cualquier constante, digamos 0, entonces
>> quedaria:
>>
>> col1 = 1, col2 = 1, col3 = 0
>> col1 = 3, col2 = 1, col3 = 0
>>
>> y aqui la restriccion de unicidad por ([col2], [col3]) dara error.
>>
>>> 2) En el caso de que la pk sea multicolumnas y sus columnas sean
>>> alfanumericas, ciertamente se podria usar el mismo criterio concatenando
>>> la
>>> pk en
>>> una sola expresion ? ej. case when col1 in (1,3) then '0' else
>>> pkcol1+pkcol2 end.
>>
>> La concatenacion puede dar como resultado valores iguales para diferentes
>> combinaciones.
>>
>> pk1 = 'micro', pk2 = 'soft', col1 = 2, col2 = 1, col3 = 'microsoft'
>> pk1 = 'micr', pk2 = 'osoft', col1 = 4, col2 = 1, col3 = 'microsoft'
>>
>> a pesar de que la restriccion de clave primaria es unica a nivel de
>> multi-columnas, la concatenacion no lo es.y por tanto ([col2], [col3]) no
>> lo
>> es apesar de que [col1] no es 1 o 3.
>>
>>
>> AMB
>>
>>
>> "Pedro Echavarria" wrote:
>>
>>> >
>>> > ambien puedes crear una columna calculada y usar esta junto col2 para
>>> > definir una restriccion de unicidad. Este metodo funciona si tienes
>>> > una
>>> > clave
>>> > primaria que no sea multi-columnas. Supongamos que tienes:
>>> >
>>>
>>> Leyendo esa interesante idea me surgen estas preguntas, amigo Alejandro:
>>>
>>> 1) Si uno en vez de poner "then 0" pone la misma columna en cuestion
>>> (ej:
>>> col3 as case when col1 in (1, 3) then col1 else pk end ), no se
>>> obtendria la
>>> misma utilidad? E incluso la restriccion podria dejarse para solo la
>>> columna calculada col3 ej: constraint uq_t1_coll3 unique (col3). Es asi
>>> o
>>> lo he interpretado mal ?
>>>
>>> 2) En el caso de que la pk sea multicolumnas y sus columnas sean
>>> alfanumericas, ciertamente se podria usar el mismo criterio concatenando
>>> la
>>> pk en
>>> una sola expresion ? ej. case when col1 in (1,3) then '0' else
>>> pkcol1+pkcol2 end.
>>>
>>>
>>>
>>>
>>>
>>>
>
>