Today, a friend at work asked me a question "how to sort in a stored procedure?" Of course there is a simple answer:
CREATE PROCEDURE [dbo].[Sorter]()
AS
SELECT * FROM Table ORDER BY Field
But... what if you want to order by any field of the table? That is a "dynamic order by"... well then: CREATE PROCEDURE [dbo].[Sorter](@SortOrder tinyint = NULL AS SELECT Field1, Field2, Field3 FROM Customers ORDER BY CASE WHEN @SortOrder = 1 THEN Field1 WHEN @SortOrder = 2 THEN Field2 ELSE Field3 END
Great!... well not that much, because it only works as expected if all 3 fields are of the same type (of course we could convert them all to string... I mean "nchar")
My friend has all this problems because he is trying to avoid the dynamic slq approach (either creating his own dynamic sql generator, or using any of the available ORMs)
But this post is about LINQ... with LINQ, we will have relational extensions right there inside C#... that means no more language mixing (SQL inside strings inside C#)... but that also means... no more dynamic manipulation of SQL (AFAIK C# can not manipulate C# as a string, they way it does with SQL)... So... will LINQ really simplify development of data manipulation applications? or will it complicate it more by preventing us from easly and dinamically manipulate queries ? or is this just an SQL limitation (maybe SQL should allow as to have parametrized sorting?)?
I guess I'll have to do more research...
2 comments:
hey!! No sabia que tenias un blog,
digo no puedo opinar acerca de
lo que escribes... porque no se
practicamente nada de programación,
pero, me gusta el modo en que
te has diseñado el lugar, y el modo
en que escribes es muy ordenado
no se de que hablas, pero aun asi
es divertido ver como hilas tus
pensamientos :P
Por cierto la entrada que esta
arriba, esta marcada como anónima por
dios sabe que razón, pero te la mando
tu adorado hermano, aka:maxetormer :P
Post a Comment