Codificar campos

No es polémica, pero tal y como he dicho antes, cada cosa está pensado
para algo, y SQL Server 2000 es un gestor de base de datos y eso es lo que
mejor sabe hacer.

Ahora bien, es cierto que la versión 2005 se ha desarrollado teniendo en
cuenta más funcionalidades y como tal habrá que aprovecharlas si su
rendimiento es bueno.

Son dos cosas diferentes, como ves...


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Maxi" escribió en el mensaje
news:

Carlos, no quiero entrar en polemicas pero...

En 2000 es verdad lo que dices, pero en 2005 se esta induciendo a poner

mas

cosas en el servidor, una de ellas la encriptacion que ahora es natural

pero

tambien ahora dispones de mas cosas: Web services (SODA), CLR, Service
Broker.

Estas cosas ya no estan fuera del motor sino dentro, con lo cual en los
proximos años existira un cambio en como pensamos las cosas, ahora SQl
server no es solo un motor de bdd sino es todo un conjunto de servicios
capaz de hacer una aplicacion entera (menos la capa de presentacion)

Un abrazo :-)


Salu2
Maxi [MVP SQL SERVER]


"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:
> Yo preferiría dejarlo donde está (en la aplicación) y no en el
> servidor... deja a cada parte que haga lo que mejor sabe hacer.
>
> Pero bueno, es mi opinión...
>
>
> Un saludo
>
> -
> "Sólo sé que no sé nada. " (Sócrates)
>
> "Mendez" escribió en el mensaje
> news:
>> Ok, pues muchas gracias.
>>
>> Intentare hacer algun procedimiento almacenado que me haga la
>> conversion, aunque me cueste meterlo en una DLL.
>>
>> Asi puedo llamarlo directamente para los informes y me ahorro el paso
>> por el programa.
>>
>>
>> Carlos Sacristán wrote:
>> > De forma nativa, no. En cualquier caso, si no lo hace la

aplicación

>> > cliente lo va a tener que hacer el servidor, o sea que el trabajo es

el

>> > mismo...
>> >
>> >
>> > Un saludo
>> >
>> > -
>> > "Sólo sé que no sé nada. " (Sócrates)
>> >
>> > "Mendez" escribió en el mensaje
>> > news:
>> >
>> >>Hola gente!
>> >>
>> >>Hay alguna manera de codificar un campo? Es para el tipico campo de
>> >>cuentas bancarias y cosas asi.
>> >>
>> >>Ahora lo hago por programacion, pero claro, cuando quiero sacar un
>> >>informe lo tengo que filtrar todo por mi programa y no resulta muy
>> >>eficiente para informes muy grandes.
>> >>
>> >>Gracias!!
>> >
>> >
>> >
>
>

Tal cual :-)


Salu2
Maxi [MVP SQL SERVER]


"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:

No es polémica, pero tal y como he dicho antes, cada cosa está pensado
para algo, y SQL Server 2000 es un gestor de base de datos y eso es lo que
mejor sabe hacer.

Ahora bien, es cierto que la versión 2005 se ha desarrollado teniendo
en
cuenta más funcionalidades y como tal habrá que aprovecharlas si su
rendimiento es bueno.

Son dos cosas diferentes, como ves...


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Maxi" escribió en el mensaje
news:

Carlos, no quiero entrar en polemicas pero...

En 2000 es verdad lo que dices, pero en 2005 se esta induciendo a poner

mas

cosas en el servidor, una de ellas la encriptacion que ahora es natural

pero

tambien ahora dispones de mas cosas: Web services (SODA), CLR, Service
Broker.

Estas cosas ya no estan fuera del motor sino dentro, con lo cual en los
proximos años existira un cambio en como pensamos las cosas, ahora SQl
server no es solo un motor de bdd sino es todo un conjunto de servicios
capaz de hacer una aplicacion entera (menos la capa de presentacion)

Un abrazo :-)


Salu2
Maxi [MVP SQL SERVER]


"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:
> Yo preferiría dejarlo donde está (en la aplicación) y no en el
> servidor... deja a cada parte que haga lo que mejor sabe hacer.
>
> Pero bueno, es mi opinión...
>
>
> Un saludo
>
> -
> "Sólo sé que no sé nada. " (Sócrates)
>
> "Mendez" escribió en el mensaje
> news:
>> Ok, pues muchas gracias.
>>
>> Intentare hacer algun procedimiento almacenado que me haga la
>> conversion, aunque me cueste meterlo en una DLL.
>>
>> Asi puedo llamarlo directamente para los informes y me ahorro el paso
>> por el programa.
>>
>>
>> Carlos Sacristán wrote:
>> > De forma nativa, no. En cualquier caso, si no lo hace la

aplicación

>> > cliente lo va a tener que hacer el servidor, o sea que el trabajo es

el

>> > mismo...
>> >
>> >
>> > Un saludo
>> >
>> > -
>> > "Sólo sé que no sé nada. " (Sócrates)
>> >
>> > "Mendez" escribió en el mensaje
>> > news:
>> >
>> >>Hola gente!
>> >>
>> >>Hay alguna manera de codificar un campo? Es para el tipico campo de
>> >>cuentas bancarias y cosas asi.
>> >>
>> >>Ahora lo hago por programacion, pero claro, cuando quiero sacar un
>> >>informe lo tengo que filtrar todo por mi programa y no resulta muy
>> >>eficiente para informes muy grandes.
>> >>
>> >>Gracias!!
>> >
>> >
>> >
>
>

Maxi,

En 2000 es verdad lo que dices, pero en 2005 se esta induciendo a poner mas
cosas en el servidor, una de ellas la encriptacion que ahora es natural pero
tambien ahora dispones de mas cosas: Web services (SODA), CLR, Service
Broker.

Yo me alegro mucho de esto, pues tendre mas trabajo corrigiendo y
sintonizando procesos que incluyen CLR. SQL Server 2005 lo trae "off" por
default y creo que la aceptacion de esta integracion tomara tiempo. Una de
las cosas que ha hecho popular ha sql server 2000 es que no esta ligado a
ningun lenguaje de programacion ni plataforma como CLR. Eso la hace mas
independiente.

Por seguridad, estoy de acuerdo con encryptar la data, ahora que esto se
haga desde el motor no veo porque. Una de las cosas por la que esto se ha
pasado al motor, es porque una vez encryptada desde afuera, se hace imposible
consultar la data desde adentro de sql server. Ahora, que tan eficiente y
seguro sera hacer esto desde dentro?, no se, el tiempo dira.

Yo soy muy amigo de la simplicidad, mientras mas complicados hacemos los
sistemas, mas dificil de sintonizarlos, mas oscuro son para quienes los
usamos, mas personal se necesitara para mantenerlos, etc.

Antes eramos devotos a sistemas "fat client", despues "fat server", despues
nos dimos cuentas que era mejor crear capaz dedicadas a cierta funcionalidad
(presentacion, capa media o de negocio y base de datos). Espero que no
estemos regresando atras como en la moda.


AMB

"Maxi" wrote:

Carlos, no quiero entrar en polemicas pero...

En 2000 es verdad lo que dices, pero en 2005 se esta induciendo a poner mas
cosas en el servidor, una de ellas la encriptacion que ahora es natural pero
tambien ahora dispones de mas cosas: Web services (SODA), CLR, Service
Broker.

Estas cosas ya no estan fuera del motor sino dentro, con lo cual en los
proximos años existira un cambio en como pensamos las cosas, ahora SQl
server no es solo un motor de bdd sino es todo un conjunto de servicios
capaz de hacer una aplicacion entera (menos la capa de presentacion)

Un abrazo :-)


Salu2
Maxi [MVP SQL SERVER]


"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:
> Yo preferiría dejarlo donde está (en la aplicación) y no en el
> servidor... deja a cada parte que haga lo que mejor sabe hacer.
>
> Pero bueno, es mi opinión...
>
>
> Un saludo
>
> -
> "Sólo sé que no sé nada. " (Sócrates)
>
> "Mendez" escribió en el mensaje
> news:
>> Ok, pues muchas gracias.
>>
>> Intentare hacer algun procedimiento almacenado que me haga la
>> conversion, aunque me cueste meterlo en una DLL.
>>
>> Asi puedo llamarlo directamente para los informes y me ahorro el paso
>> por el programa.
>>
>>
>> Carlos Sacristán wrote:
>> > De forma nativa, no. En cualquier caso, si no lo hace la aplicación
>> > cliente lo va a tener que hacer el servidor, o sea que el trabajo es el
>> > mismo...
>> >
>> >
>> > Un saludo
>> >
>> > -
>> > "Sólo sé que no sé nada. " (Sócrates)
>> >
>> > "Mendez" escribió en el mensaje
>> > news:
>> >
>> >>Hola gente!
>> >>
>> >>Hay alguna manera de codificar un campo? Es para el tipico campo de
>> >>cuentas bancarias y cosas asi.
>> >>
>> >>Ahora lo hago por programacion, pero claro, cuando quiero sacar un
>> >>informe lo tengo que filtrar todo por mi programa y no resulta muy
>> >>eficiente para informes muy grandes.
>> >>
>> >>Gracias!!
>> >
>> >
>> >
>
>

De acuerdo. Uso la 2000, que con lo que costó la licencia... creo que
tardaremos en actualizar a la 2005 unos cuantos años.

Creo que me decantaré por que lo haga mi programa.

Gracias a todos!!

Saludos desde Cartagena.

Maxi wrote:

Hola, en sql2000 es como dice Carlos, en sql2005 puedes encriptar

campos :-)

Ale,

Yo me alegro mucho de esto, pues tendre mas trabajo corrigiendo y
sintonizando procesos que incluyen CLR. SQL Server 2005 lo trae "off" por
default y creo que la aceptacion de esta integracion tomara tiempo. Una de
las cosas que ha hecho popular ha sql server 2000 es que no esta ligado a
ningun lenguaje de programacion ni plataforma como CLR. Eso la hace mas
independiente.

No coincido con esto, MS esta teniendo todo una sola plataforma de
integracion (VS - Sql - Office - Windows Vista) y ademas no se si vas a
tener mucho trabajo mas, quizas el mismo que tenes ahora cuando alguien
aplica mal las cosas, es como todo, lo mejor es que ahora lo tenes y antes
no lo tenias, ahora podes con sql armar todo cosa que antes era solo un
motor y nada mas, esto va a simplificar mucho las cosas si se hacen bien
claro. Ademas te comento una cosa, no creo q SQL sea mas o menos dependiente
por lo del CLR, con ese criterio SQL es dependiente de Windows ;-)

Por seguridad, estoy de acuerdo con encryptar la data, ahora que esto se
haga desde el motor no veo porque. Una de las cosas por la que esto se ha
pasado al motor, es porque una vez encryptada desde afuera, se hace
imposible
consultar la data desde adentro de sql server. Ahora, que tan eficiente y
seguro sera hacer esto desde dentro?, no se, el tiempo dira.

Es muy eficiente de verdad, trabaja de una manera muy segura y como te dije
antes, no necesitas ahora depender de herramientas de terceros (que te
hacian las cosas mas lentas) o de algun programador que ponga su sistema de
encriptacion, ahora tenes sistemas de encriptacion standares y es muy
seguro, el otro dia mostramos en una charla esto :-)

Antes eramos devotos a sistemas "fat client", despues "fat server",
despues
nos dimos cuentas que era mejor crear capaz dedicadas a cierta
funcionalidad
(presentacion, capa media o de negocio y base de datos). Espero que no
estemos regresando atras como en la moda.

No creo que sean modas, la velocidad en que se mueven las tecnologias hacen
que parezca eso, pero veamos una cosa, hoy dia para trabajar con SOA debes
hacer

1) SQL con SP
2) Tu aplicacion Web Service
3) Consumir este Web service

Ahora con SQL no necesitas el punto 2 por ej.

Otra cosa, si hoy querias poner logica de negocios mas compleja en la bdd no
podias (TSQL es muy limitado), ahora con CLR podes, un simple ejemplo de
esto: Como haces para armar tu propia funcion de Agregacion?
Ademas, la velocidad con que crece CLR es muy superior a la que crece TSQL
con lo cual estan haciendo de SQL no solo un motor de bdd sino un servidor
de aplicacion. Y aun hay mas, por ahora tenemos BDD relacionales, puess el
mundo de las relacionales esta llegando a un punto (por no decir fin) donde
ya se esta pensando en BDD OOP.

Bue hay muchas cosas, el cambio no es simple, para mi lo que se ha hecho hoy
con SQL+VS+Windows+Offfice es algo que nunca vi y la verdad es muy bueno,
esperemos a ver que adopta la industria.

Un abrazo


Salu2
Maxi [MVP SQL SERVER]


"Alejandro Mesa" escribió en el
mensaje news:

Maxi,

En 2000 es verdad lo que dices, pero en 2005 se esta induciendo a poner
mas
cosas en el servidor, una de ellas la encriptacion que ahora es natural
pero
tambien ahora dispones de mas cosas: Web services (SODA), CLR, Service
Broker.

Yo me alegro mucho de esto, pues tendre mas trabajo corrigiendo y
sintonizando procesos que incluyen CLR. SQL Server 2005 lo trae "off" por
default y creo que la aceptacion de esta integracion tomara tiempo. Una de
las cosas que ha hecho popular ha sql server 2000 es que no esta ligado a
ningun lenguaje de programacion ni plataforma como CLR. Eso la hace mas
independiente.

Por seguridad, estoy de acuerdo con encryptar la data, ahora que esto se
haga desde el motor no veo porque. Una de las cosas por la que esto se ha
pasado al motor, es porque una vez encryptada desde afuera, se hace
imposible
consultar la data desde adentro de sql server. Ahora, que tan eficiente y
seguro sera hacer esto desde dentro?, no se, el tiempo dira.

Yo soy muy amigo de la simplicidad, mientras mas complicados hacemos los
sistemas, mas dificil de sintonizarlos, mas oscuro son para quienes los
usamos, mas personal se necesitara para mantenerlos, etc.

Antes eramos devotos a sistemas "fat client", despues "fat server",
despues
nos dimos cuentas que era mejor crear capaz dedicadas a cierta
funcionalidad
(presentacion, capa media o de negocio y base de datos). Espero que no
estemos regresando atras como en la moda.


AMB

"Maxi" wrote:

Carlos, no quiero entrar en polemicas pero...

En 2000 es verdad lo que dices, pero en 2005 se esta induciendo a poner
mas
cosas en el servidor, una de ellas la encriptacion que ahora es natural
pero
tambien ahora dispones de mas cosas: Web services (SODA), CLR, Service
Broker.

Estas cosas ya no estan fuera del motor sino dentro, con lo cual en los
proximos años existira un cambio en como pensamos las cosas, ahora SQl
server no es solo un motor de bdd sino es todo un conjunto de servicios
capaz de hacer una aplicacion entera (menos la capa de presentacion)

Un abrazo :-)


Salu2
Maxi [MVP SQL SERVER]


"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:
> Yo preferiría dejarlo donde está (en la aplicación) y no en el
> servidor... deja a cada parte que haga lo que mejor sabe hacer.
>
> Pero bueno, es mi opinión...
>
>
> Un saludo
>
> -
> "Sólo sé que no sé nada. " (Sócrates)
>
> "Mendez" escribió en el mensaje
> news:
>> Ok, pues muchas gracias.
>>
>> Intentare hacer algun procedimiento almacenado que me haga la
>> conversion, aunque me cueste meterlo en una DLL.
>>
>> Asi puedo llamarlo directamente para los informes y me ahorro el paso
>> por el programa.
>>
>>
>> Carlos Sacristán wrote:
>> > De forma nativa, no. En cualquier caso, si no lo hace la
>> > aplicación
>> > cliente lo va a tener que hacer el servidor, o sea que el trabajo es
>> > el
>> > mismo...
>> >
>> >
>> > Un saludo
>> >
>> > -
>> > "Sólo sé que no sé nada. " (Sócrates)
>> >
>> > "Mendez" escribió en el mensaje
>> > news:
>> >
>> >>Hola gente!
>> >>
>> >>Hay alguna manera de codificar un campo? Es para el tipico campo de
>> >>cuentas bancarias y cosas asi.
>> >>
>> >>Ahora lo hago por programacion, pero claro, cuando quiero sacar un
>> >>informe lo tengo que filtrar todo por mi programa y no resulta muy
>> >>eficiente para informes muy grandes.
>> >>
>> >>Gracias!!
>> >
>> >
>> >
>
>