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