Usa un generador de código para generar los stored procedures.. -- -------------------------------- Ing. José Mariano Alvarez SQL Total Consulting Bogota 3631 P3B 1407 Buenos Aires-Argentina Movil: (011)-15-4184-7541 Desde el exterior: (+54-911)-4184-7541 [email protected]
2009/1/11 Oscar Onorato <[email protected]> > Gracias Maimiliano, > > Saludos! > > El 11 de enero de 2009 21:44, Maxi Accotto <[email protected]>escribió: > > Hola, si existe, y se llama SQL Dinamico! Y no veo aun el motivo de >> ventaja, no veo que haya código harcodeado, sino todo sp estaría asi porque >> indica atributos, tablas, etc. >> >> >> >> Yo no pensaría los Store como métodos, no existe un método en la base de >> datos, los métodos son del mundo de objetos y a menos que uses una base >> orientada a objetos no encontraras ese concepto y no recomiendo que apliques >> porque son pensadas en forma relacional. >> >> >> >> >> >> Saludos >> >> >> >> *Maximiliano Damian Accotto* >> >> *Microsoft MVP en SQLServer* >> >> *SQL Total Consulting - Servicios profesionales en SQL Server* >> >> *Buenos Aires-Argentina* >> >> *Movil: (011)-15-5868-5599* >> >> *Desde el exterior: (+54-911)-5868-5599* >> >> *[email protected]<[email protected]> >> * >> >> *im: [email protected]* >> >> >> >> >> >> *De:* [email protected] [mailto:[email protected]] *En nombre de *Oscar >> Onorato >> *Enviado el:* domingo, 11 de enero de 2009 07:04 p.m. >> *Para:* Maxi >> *Asunto:* [dbms] Re: Re: [dbms] Stored Procedures pensados como Métodos >> >> >> >> Gracias Maximiliano por la respuesta, >> >> >> >> Pero en el email inicial estaba una de las respuestas a tus preguntas: >> >> >> >> *Por una lado en el Asunto:* "Stored Procedures pensados como Métodos". >> >> *Y luego en el cuerpo del e-mail:* "O qué opciones tengo para no >> andar reescribiendo el mismo tipo de consulta con distintos nombre/s." >> >> >> >> Aunque tu respuesta me sirve para tener presente la cuestión sobre la >> seguridad. Que, como a creo que todos, nos importa y mucho. >> >> >> >> Aun así, me llama la atención que no exista, intrínseco a SQL Server, un >> modo de crear querys que pueden ser muy similares cuando lo que varía no es >> la lógica de la consulta sino sus elementos estáticos (objetos de la BD). >> >> >> >> El motivo concreto es escribir menos código "harcodeado" en forma de >> SP's. Es una percepción de alguien que no es Administrador de BD's, sino >> programador. Por eso el título del Asunto. >> >> >> >> >> >> Gracias Maximiliano >> >> El 11 de enero de 2009 19:29, Maxi Accotto <[email protected]> >> escribió: >> >> Hola Oscar, y cual es la ventaja de tener un solo sp? ocupar menos >> >> espacio?, si queres generalizar este tipo de cosas vas a terminar >> haciendo sql dinamico (sp_executesql) o bien if dentro del sp. >> Cualquiera de los dos metodos no ayudan a la performance y el primero >> atenta contra uno de los objetivos de los Stores que es la seguridad, >> si eso no te importa entonces dale para adelante. >> >> Ahora bien, a mi no me preocuparia tener mas de un sp ya que hacen >> cosas totalmente distintas, pero bueno esa es mi recomendacion nomas >> >> El día 11 de enero de 2009 15:30, Oscar Onorato >> <[email protected]> escribió: >> > Hola lista! >> > >> > Tengo, hasta el momento, 3 SP's similares que sólo cambian en: >> > >> > 1. El nombre del SP >> > 2. El nombre del parámetro de entrada (es sólo uno en los 3 casos) >> > 3. Los nombres de los campos a consultar >> > 4. La cantidad de campos a consultar >> > 5. El nombre de la tabla a consultar >> > >> > En los 3 SP's los 5 púntos son una constante, y creo que debo tener más >> > similares. Pero por ahora son estas las similares. >> > La pregunta es ¿tengo forma de hacer una parametrización de este tipo de >> > consultas para llevarlas a un sólo SP o UDF con parámetros genéricos? >> > >> > La idea es usar sólo objeto de la BD (SP's o UDF's) para realizar el >> mismo >> > tipo de consulta. Sin recurrir al CLR. O qué opciones tengo para no >> andar >> > reescribiendo lo mismo tipo de consulta con distintos nombre/s. >> > En realidad estoy pensando estas consultas como un sólo método que >> acepta >> > varios parámetros. En realidad todos aquellos necesarios para no andar >> > reescribiendo sólo para hacer referencia a nombres distintos y/o >> cantidades >> > de campos. >> > Como veran la estructura de las consultas es la misma. >> > >> > Estos son los SP's de los que hablo: >> > >> > CREATE PROCEDURE GetDepartmentDetails >> > (@DepartmentID INT) >> > AS >> > SELECT Name, Description >> > FROM Department >> > WHERE DepartmentID = @DepartmentID >> > CREATE PROCEDURE GetCategoryDetails >> > (@CategoryID INT) >> > AS >> > SELECT DepartmentID, Name, Description >> > FROM Category >> > WHERE CategoryID = @CategoryID >> > CREATE PROCEDURE GetProductDetails >> > (@ProductID INT) >> > AS >> > SELECT Name, Description, Price, Image1FileName, Image2FileName, >> > OnDepartmentPromotion, OnCatalogPromotion >> > FROM Product >> > WHERE ProductID = @ProductID >> > >> > >> > Gracias >> >> >> >> -- >> ----------------------------------------------------------- >> Microsoft MVP en SQL Server >> Consultor en SQLTotalConsulting >> Excelencia en servicios y consultoria SQLServer >> www.sqltotalconsulting.com >> ----------------------------------------------------------- >> >> >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com >> Version: 8.0.176 / Virus Database: 270.10.5/1884 - Release Date: >> 09/01/2009 07:59 p.m. >> > >
