Tal cual J
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 <mailto:[email protected]> [email protected] im: [email protected] De: [email protected] [mailto:[email protected]] En nombre de Jose Mariano Alvarez Enviado el: domingo, 11 de enero de 2009 08:27 p.m. Para: Maxi Asunto: [dbms] Re: Re: RE: [dbms] Re: Re: [dbms] Stored Procedures pensados como Métodos 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] <mailto:[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 <http://www.sqltotalconsulting.com/> ----------------------------------------------------------- No virus found in this incoming message. Checked by AVG - http://www.avg.com <http://www.avg.com/> Version: 8.0.176 / Virus Database: 270.10.5/1884 - Release Date: 09/01/2009 07:59 p.m. 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.
