LINQ and the future of database design/programming
-
I'm reading a bit on LINQ; it seems very interesting - I almost get the feeling that this could be a very big thing. Even though I wouldn't go so far, some people out there even think that it may toss the good old database best practices out of the window: stuff like "if the backend can, the backend SHALL", stored procedures etc., so basically treating the database as a loose shcema bit bucket. How do you fell about this? Is something "big" underway? Sometimes old practices die and new ones emerge although I love the stability/flexibility of stored procedures.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn Rand -
I'm reading a bit on LINQ; it seems very interesting - I almost get the feeling that this could be a very big thing. Even though I wouldn't go so far, some people out there even think that it may toss the good old database best practices out of the window: stuff like "if the backend can, the backend SHALL", stored procedures etc., so basically treating the database as a loose shcema bit bucket. How do you fell about this? Is something "big" underway? Sometimes old practices die and new ones emerge although I love the stability/flexibility of stored procedures.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn RandLINQ is interesting, but I fear that it's greatest use ( linking together disparate data sources ), will often be used in ways that turn out to be very costly.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
I'm reading a bit on LINQ; it seems very interesting - I almost get the feeling that this could be a very big thing. Even though I wouldn't go so far, some people out there even think that it may toss the good old database best practices out of the window: stuff like "if the backend can, the backend SHALL", stored procedures etc., so basically treating the database as a loose shcema bit bucket. How do you fell about this? Is something "big" underway? Sometimes old practices die and new ones emerge although I love the stability/flexibility of stored procedures.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn RandI hate writing and using and especially debugging stored procedures, i hate convoluted SQL performing calculations that would have been trivial to do in procedural code, and i really hate writing procedural code to perform queries. It's as if DLINQ was designed to make me happy... so yeah, i'm still waiting for the other shoe to drop. ;)
----
Yes, but can you blame them for doing so if that's the only legal way they can hire programmers they want at the rate they can afford?
-- Nish on sketchy hiring practices
-
I'm reading a bit on LINQ; it seems very interesting - I almost get the feeling that this could be a very big thing. Even though I wouldn't go so far, some people out there even think that it may toss the good old database best practices out of the window: stuff like "if the backend can, the backend SHALL", stored procedures etc., so basically treating the database as a loose shcema bit bucket. How do you fell about this? Is something "big" underway? Sometimes old practices die and new ones emerge although I love the stability/flexibility of stored procedures.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn RandDLinq is a big mess[^] What's wrong with DLinq? Here's the list I have so far: attribute-based, MS Sql Server only, overly complicated, poor stored proc support, no server-side paging, very limited functionality, and no WinFS/OPath integration. I've commented on why attributes are superior to attributes before, and others are already chiming in on this, so I'm simply going to point out that they've failed in delivering their own goal to be "non-intrusive", which is stated in the DLinq docs. Next, while many people don't care about being able to simultaneously targetting multiple databases, its also very true that many people that target only one database do NOT work with MS Sql Server! DLinq is needlessly complex because it actually expects you to know a lot more than just ADO.NET and Sql, much like XLinq expects too much Xml knowledge. Consider their example query "from c in db.Customers where c.City == 'London' select c;" -- note that db.Customers only works because they have elsewhere defined Customers as a Table type. But you've already marked your Customer class with the attribute "Table(Name = 'Customers')", not too mention all the Column attributes -- so why isn't the attribute enough to make it clear what "Customers" refers to? etc. I'm beginning to sound like a broken record, but: 1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance. 2. I fundamentally disagree with entangling the schema with the UI presentation via tables. That's what views (and why they are called views) are for. They allow me to modify the schema without rewriting the visualization code. 3. I fundamentally disagree with interactions in application code that entangles non-abstracted (table again rather than view) schema with application-specific code. Again, change the schema, change the code. It creates brittle applications. 4. I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code. 5. I'm not a fan of stored procedures, so for me, that's not an acceptable alternative. The only possible place that DLinq makes sense is in business rules, and then it still only makes sense of you'
-
DLinq is a big mess[^] What's wrong with DLinq? Here's the list I have so far: attribute-based, MS Sql Server only, overly complicated, poor stored proc support, no server-side paging, very limited functionality, and no WinFS/OPath integration. I've commented on why attributes are superior to attributes before, and others are already chiming in on this, so I'm simply going to point out that they've failed in delivering their own goal to be "non-intrusive", which is stated in the DLinq docs. Next, while many people don't care about being able to simultaneously targetting multiple databases, its also very true that many people that target only one database do NOT work with MS Sql Server! DLinq is needlessly complex because it actually expects you to know a lot more than just ADO.NET and Sql, much like XLinq expects too much Xml knowledge. Consider their example query "from c in db.Customers where c.City == 'London' select c;" -- note that db.Customers only works because they have elsewhere defined Customers as a Table type. But you've already marked your Customer class with the attribute "Table(Name = 'Customers')", not too mention all the Column attributes -- so why isn't the attribute enough to make it clear what "Customers" refers to? etc. I'm beginning to sound like a broken record, but: 1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance. 2. I fundamentally disagree with entangling the schema with the UI presentation via tables. That's what views (and why they are called views) are for. They allow me to modify the schema without rewriting the visualization code. 3. I fundamentally disagree with interactions in application code that entangles non-abstracted (table again rather than view) schema with application-specific code. Again, change the schema, change the code. It creates brittle applications. 4. I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code. 5. I'm not a fan of stored procedures, so for me, that's not an acceptable alternative. The only possible place that DLinq makes sense is in business rules, and then it still only makes sense of you'
Nice post!
Marc Clifton wrote:
1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance.
But isn't that sometimes the logical design? What's the alternative? Sometimes the shoe fits and your BOL needs to move the data to the DAL.
Marc Clifton wrote:
I fundamentally disagree with interactions in application code that entangles non-abstracted (table again rather than view) schema with application-specific code. Again, change the schema, change the code. It creates brittle applications.
Agreed,
Marc Clifton wrote:
I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code.
That's why stored procedures are beautiful :):)
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn Rand -
DLinq is a big mess[^] What's wrong with DLinq? Here's the list I have so far: attribute-based, MS Sql Server only, overly complicated, poor stored proc support, no server-side paging, very limited functionality, and no WinFS/OPath integration. I've commented on why attributes are superior to attributes before, and others are already chiming in on this, so I'm simply going to point out that they've failed in delivering their own goal to be "non-intrusive", which is stated in the DLinq docs. Next, while many people don't care about being able to simultaneously targetting multiple databases, its also very true that many people that target only one database do NOT work with MS Sql Server! DLinq is needlessly complex because it actually expects you to know a lot more than just ADO.NET and Sql, much like XLinq expects too much Xml knowledge. Consider their example query "from c in db.Customers where c.City == 'London' select c;" -- note that db.Customers only works because they have elsewhere defined Customers as a Table type. But you've already marked your Customer class with the attribute "Table(Name = 'Customers')", not too mention all the Column attributes -- so why isn't the attribute enough to make it clear what "Customers" refers to? etc. I'm beginning to sound like a broken record, but: 1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance. 2. I fundamentally disagree with entangling the schema with the UI presentation via tables. That's what views (and why they are called views) are for. They allow me to modify the schema without rewriting the visualization code. 3. I fundamentally disagree with interactions in application code that entangles non-abstracted (table again rather than view) schema with application-specific code. Again, change the schema, change the code. It creates brittle applications. 4. I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code. 5. I'm not a fan of stored procedures, so for me, that's not an acceptable alternative. The only possible place that DLinq makes sense is in business rules, and then it still only makes sense of you'
Marc Clifton wrote:
So, what's the latest on Microsoft's Entity Framework? Or has it already gone to the same bit bucket in the sky as Object Spaces?
There was a big piece about it in this month's MS Propagana News (MSDN Magazine :) ) - i'm very intrigued by it as I'm lazy, and hate writing tedious data access code.
-
I hate writing and using and especially debugging stored procedures, i hate convoluted SQL performing calculations that would have been trivial to do in procedural code, and i really hate writing procedural code to perform queries. It's as if DLINQ was designed to make me happy... so yeah, i'm still waiting for the other shoe to drop. ;)
----
Yes, but can you blame them for doing so if that's the only legal way they can hire programmers they want at the rate they can afford?
-- Nish on sketchy hiring practices
Ok., I see your point :) I, on the other hand, like SQL programming. I do agree on the nastiness on writing proecdural querying code. Just feels unnatural.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn Rand -
DLinq is a big mess[^] What's wrong with DLinq? Here's the list I have so far: attribute-based, MS Sql Server only, overly complicated, poor stored proc support, no server-side paging, very limited functionality, and no WinFS/OPath integration. I've commented on why attributes are superior to attributes before, and others are already chiming in on this, so I'm simply going to point out that they've failed in delivering their own goal to be "non-intrusive", which is stated in the DLinq docs. Next, while many people don't care about being able to simultaneously targetting multiple databases, its also very true that many people that target only one database do NOT work with MS Sql Server! DLinq is needlessly complex because it actually expects you to know a lot more than just ADO.NET and Sql, much like XLinq expects too much Xml knowledge. Consider their example query "from c in db.Customers where c.City == 'London' select c;" -- note that db.Customers only works because they have elsewhere defined Customers as a Table type. But you've already marked your Customer class with the attribute "Table(Name = 'Customers')", not too mention all the Column attributes -- so why isn't the attribute enough to make it clear what "Customers" refers to? etc. I'm beginning to sound like a broken record, but: 1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance. 2. I fundamentally disagree with entangling the schema with the UI presentation via tables. That's what views (and why they are called views) are for. They allow me to modify the schema without rewriting the visualization code. 3. I fundamentally disagree with interactions in application code that entangles non-abstracted (table again rather than view) schema with application-specific code. Again, change the schema, change the code. It creates brittle applications. 4. I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code. 5. I'm not a fan of stored procedures, so for me, that's not an acceptable alternative. The only possible place that DLinq makes sense is in business rules, and then it still only makes sense of you'
Marc Clifton wrote:
How does DLinq address my concerns? Frankly, I don't think it does.
What O/RM do you use Marc? NHibernate[^] pretty much addresses all of those concerns.
-
LINQ is interesting, but I fear that it's greatest use ( linking together disparate data sources ), will often be used in ways that turn out to be very costly.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Christian Graus wrote:
but I fear that it's greatest use ( linking together disparate data sources ), will often be used in ways that turn out to be very costly.
How so?
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn Rand -
I hate writing and using and especially debugging stored procedures, i hate convoluted SQL performing calculations that would have been trivial to do in procedural code, and i really hate writing procedural code to perform queries. It's as if DLINQ was designed to make me happy... so yeah, i'm still waiting for the other shoe to drop. ;)
----
Yes, but can you blame them for doing so if that's the only legal way they can hire programmers they want at the rate they can afford?
-- Nish on sketchy hiring practices
So what...you're checking the Lounge...but not other forums for interesting messages that might pertain to you? ;P
-
Marc Clifton wrote:
How does DLinq address my concerns? Frankly, I don't think it does.
What O/RM do you use Marc? NHibernate[^] pretty much addresses all of those concerns.
David Stone wrote:
What O/RM do you use Marc?
I primarily don't use an ORM. I use Interacx. For the business rules, I use a lightweight class generator that Justin and I have an article on (yes, it's a little klunky). Marc
-
So what...you're checking the Lounge...but not other forums for interesting messages that might pertain to you? ;P
David Stone wrote:
So what...you're checking the Lounge...but not other forums for interesting messages that might pertain to you?
Yup! Actually, I'm trying to come up with a way of explaining why we can't release because of the one key change i've been too lazy to check in... but, you know, that sounds like work and it's my day off... ;P
----
Yes, but can you blame them for doing so if that's the only legal way they can hire programmers they want at the rate they can afford?
-- Nish on sketchy hiring practices
-
Marc Clifton wrote:
So, what's the latest on Microsoft's Entity Framework? Or has it already gone to the same bit bucket in the sky as Object Spaces?
There was a big piece about it in this month's MS Propagana News (MSDN Magazine :) ) - i'm very intrigued by it as I'm lazy, and hate writing tedious data access code.
martin_hughes wrote:
i'm very intrigued by it as I'm lazy, and hate writing tedious data access code.
Take a close look at it. I went to a presentation on it a couple months ago and was moderately impressed. There were still some questions that could not be answered because it's still in development. My primary concerns though involve features that I put a lot of thought into for my Interacx system, and which I have written several articles about here (data transaction logging). My architecture supports smart client (disconnected) mode, business rules triggered on field and record transactions, sandboxing and undo/redo capability. Before I consider Entity Framework, I want to see those things in action. Marc
-
David Stone wrote:
So what...you're checking the Lounge...but not other forums for interesting messages that might pertain to you?
Yup! Actually, I'm trying to come up with a way of explaining why we can't release because of the one key change i've been too lazy to check in... but, you know, that sounds like work and it's my day off... ;P
----
Yes, but can you blame them for doing so if that's the only legal way they can hire programmers they want at the rate they can afford?
-- Nish on sketchy hiring practices
Day off...pfft. Everybody knows our days off are spent slaving over Javascript. ;P Actually...now that I'm jobless, I have every day off! :-D
-
DLinq is a big mess[^] What's wrong with DLinq? Here's the list I have so far: attribute-based, MS Sql Server only, overly complicated, poor stored proc support, no server-side paging, very limited functionality, and no WinFS/OPath integration. I've commented on why attributes are superior to attributes before, and others are already chiming in on this, so I'm simply going to point out that they've failed in delivering their own goal to be "non-intrusive", which is stated in the DLinq docs. Next, while many people don't care about being able to simultaneously targetting multiple databases, its also very true that many people that target only one database do NOT work with MS Sql Server! DLinq is needlessly complex because it actually expects you to know a lot more than just ADO.NET and Sql, much like XLinq expects too much Xml knowledge. Consider their example query "from c in db.Customers where c.City == 'London' select c;" -- note that db.Customers only works because they have elsewhere defined Customers as a Table type. But you've already marked your Customer class with the attribute "Table(Name = 'Customers')", not too mention all the Column attributes -- so why isn't the attribute enough to make it clear what "Customers" refers to? etc. I'm beginning to sound like a broken record, but: 1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance. 2. I fundamentally disagree with entangling the schema with the UI presentation via tables. That's what views (and why they are called views) are for. They allow me to modify the schema without rewriting the visualization code. 3. I fundamentally disagree with interactions in application code that entangles non-abstracted (table again rather than view) schema with application-specific code. Again, change the schema, change the code. It creates brittle applications. 4. I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code. 5. I'm not a fan of stored procedures, so for me, that's not an acceptable alternative. The only possible place that DLinq makes sense is in business rules, and then it still only makes sense of you'
Now, unless I'm missing something, it would be theoretically possible for you to build on Linq and provide the benefits of Linq in Interacx. Now, that would be cool.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
-
Now, unless I'm missing something, it would be theoretically possible for you to build on Linq and provide the benefits of Linq in Interacx. Now, that would be cool.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
Pete O`Hanlon wrote:
it would be theoretically possible for you to build on Linq and provide the benefits of Linq in Interacx.
I'm keeping my eye on it, but you have to recall that the foundation of the Interacx system is logging transactions on DataTables. I'm not sure DLinq uses DataTables as the underlying building block. And if Paul Wilson is correct when he writes ...for MS pushing stored procs so heavily, they haven't really thought out how to support stored procs very well for persistence -- again this wouldn't be a big issue if this wasn't their third attempt. So you have to write your own insert, update, and delete methods, mark them with the appropriate attributes, and supply all the logic, including the stored proc name and parameters, in your own code... , then that's definitely contrary to the auto-SQL generation that Interacx uses. There might be something doable under the DLinq hood in the graphs that it builds. Marc
-
Pete O`Hanlon wrote:
it would be theoretically possible for you to build on Linq and provide the benefits of Linq in Interacx.
I'm keeping my eye on it, but you have to recall that the foundation of the Interacx system is logging transactions on DataTables. I'm not sure DLinq uses DataTables as the underlying building block. And if Paul Wilson is correct when he writes ...for MS pushing stored procs so heavily, they haven't really thought out how to support stored procs very well for persistence -- again this wouldn't be a big issue if this wasn't their third attempt. So you have to write your own insert, update, and delete methods, mark them with the appropriate attributes, and supply all the logic, including the stored proc name and parameters, in your own code... , then that's definitely contrary to the auto-SQL generation that Interacx uses. There might be something doable under the DLinq hood in the graphs that it builds. Marc
I was thinking more along the lines about building up from Linq rather than DLinq. Theoretically, it should be possible.
Please visit http://www.readytogiveup.com/ and do something special today. Deja View - the feeling that you've seen this post before.
-
Nice post!
Marc Clifton wrote:
1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance.
But isn't that sometimes the logical design? What's the alternative? Sometimes the shoe fits and your BOL needs to move the data to the DAL.
Marc Clifton wrote:
I fundamentally disagree with interactions in application code that entangles non-abstracted (table again rather than view) schema with application-specific code. Again, change the schema, change the code. It creates brittle applications.
Agreed,
Marc Clifton wrote:
I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code.
That's why stored procedures are beautiful :):)
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn RandRohde wrote:
But isn't that sometimes the logical design?
Logical only for the moment. I guess I come from a bizarre background where 1) I'm developing frameworks to handle unknown customer applications and 2) the requirements change quite a bit as use cases are explored, since nobody has done this sort of stuff before and we really don't know about usability until we watch people using the applications. And changes in usability changes the information we want to manage which changes the schema which changes the UI. Thank goodness I don't have to change the code or the SQL! Like I said, it makes sense at the business rule level, but again using views not tables. Marc
-
Christian Graus wrote:
but I fear that it's greatest use ( linking together disparate data sources ), will often be used in ways that turn out to be very costly.
How so?
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn RandHow do you connect an array and an XML document to a stored proc, without running the stored proc first, then filtering the full result, in memory ?
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
martin_hughes wrote:
i'm very intrigued by it as I'm lazy, and hate writing tedious data access code.
Take a close look at it. I went to a presentation on it a couple months ago and was moderately impressed. There were still some questions that could not be answered because it's still in development. My primary concerns though involve features that I put a lot of thought into for my Interacx system, and which I have written several articles about here (data transaction logging). My architecture supports smart client (disconnected) mode, business rules triggered on field and record transactions, sandboxing and undo/redo capability. Before I consider Entity Framework, I want to see those things in action. Marc
I think my needs (or wants) will probably be less exacting than yours, in that I don't really have the skills, expertise, knowledge or know-how (and probably imagination!) to roll something like your Interacx architecture (looks like a fascinating couple of articles, btw, I will delve deep when time permits). In a sense, I guess I'm more of a "business" programmer in that the reason I write code is to solve business problems in my sphere of influence (I'm a glorified stores manager :) ), and what I need from development tools is the path of least effort/time - so if I can just point a tool at a database and say "go do this bit for me" then I'm more than happy, and probably won't question the why's and wherefore's that better equiped folk will. I do find software architecture a fascinating subject though :) I do find it odd, however, that although objects in programming are rapidly becoming the norm, database have stuck with the relational model through and through and that most developers seem to accept this situation and invest huge amounts of time and resource into bridging the gap. Surely (and I know there are some out there) object databases should become the norm?