Hola, Yo lo usé, una función para calcular un hash medio raro que era imposible con T SQL, ahora, tenés impacto en la performance, pero cada caso es para analizarlo en particular, porque si usás cosas fuera de el set reducido de librerías que trae SQL instaldo de .net por defecto tenés que ponerte a instalarlas y darles permiso, etc. o sea, está bueno, en el caso que yo lo usé era la más elegante de las soluciones, pero yo no desestimaría la potencia de TSQL para hacer cosas complejas. Por eso es que cada caso es para analizar.
Saludos, 2008/7/18 Ricardo Crespini <[EMAIL PROTECTED]>: > Buenas tardes, tengo entendido que desde SQL 2005, podemos escribir stored > procedures o triggers con lenguajes de .Net. Incluso que se pueden definir > tipos de datos. > > He leído en BOL que un SP / trigger o UDF escrito así podría resolver > "cálculos complejos" que resultarían muy dificiles o imposibles de manejar > con T-SQL. También en BOL mencionan como una ventaja que se podría > acceder a la librería de clases del Framework. > > Ahora, yo me pregunto: Si en una app se deben realizar cálculos complejos o > usar librerías especiales, no se deberían implementar esas funciones en el > lado cliente ? Entiendo que si el motor devuelve los datos "crudos" y el > cliente se ocupa de los manejos complejos, no "distraigo" la potencia de > procesamiento del motor en realizar tareas que puede realizar otro > componente. > > Uds. que opinan ? > > Alguien que haya usado esta funcionalidad, podría mencionar para que > situación la aplicó ? > > Gracias para todos, > Ricardo. > > ________________________________ > Ingresá ya a MSN Deportes y enterate de las últimas novedades del mundo > deportivo. MSN Deportes -- Leonardo Micheloni. Ayudando a organizar las primeras jornadas ágiles de Latinoamérica http://agiles2008.org/ Blog Personal http://leomicheloni.blogspot.com/
