LINQ and the future of database design/programming
-
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 -
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 -
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.
-
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?
-
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
David Stone wrote:
Actually...now that I'm jobless, I have every day off!
Yeah, what's the story there? I thought students were supposed to go jobless in the fall, not summer...
----
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 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?
martin_hughes wrote:
and what I need from development tools is the path of least effort/time
That definitely makes sense. :) I'm not advocating one solution fits all, but in my corner of the world, I've discovered I need solutions capable of handling dynamic requirements. Ah, I've been wishing lately for a straight forward project. Something that doesn't involve dealing with the quartz.dll and thread-processor affinity problems, or the CoreAVC codec and how the API call to the mediaController.Stop method hangs. Or a miriad of other problems dealing with USB, DVD's, networks, etc. Where's my Commodore 64!?!?!?
martin_hughes wrote:
Surely (and I know there are some out there) object databases should become the norm?
I think there's something to be said for a database optimized for data access and/or storage rather than optimized for the convenience of the programmer. :) Marc
-
martin_hughes wrote:
and what I need from development tools is the path of least effort/time
That definitely makes sense. :) I'm not advocating one solution fits all, but in my corner of the world, I've discovered I need solutions capable of handling dynamic requirements. Ah, I've been wishing lately for a straight forward project. Something that doesn't involve dealing with the quartz.dll and thread-processor affinity problems, or the CoreAVC codec and how the API call to the mediaController.Stop method hangs. Or a miriad of other problems dealing with USB, DVD's, networks, etc. Where's my Commodore 64!?!?!?
martin_hughes wrote:
Surely (and I know there are some out there) object databases should become the norm?
I think there's something to be said for a database optimized for data access and/or storage rather than optimized for the convenience of the programmer. :) Marc
Marc Clifton wrote:
Where's my Commodore 64!?!?!?
Probably in the same place as mine - the loft :)
Marc Clifton wrote:
Something that doesn't involve dealing with the quartz.dll and thread-processor affinity problems, or the CoreAVC codec and how the API call to the mediaController.Stop method hangs. Or a miriad of other problems dealing with USB, DVD's, networks, etc.
[schoom!] (Which is, of course, the internationally recognised sound of something passing over one's head at high velocity) I'm sure once quantum computing becomes the norm, and they can all simultaneously and spontaneously calculate God's phone number, our troubles will be behind us :)
-
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 never have understood why programmers dislike relational SQL databases so much. The age of fine-tuned, fast performing, tightly coded applications is rapidly ending (actually it ended a couple years ago). The practice of programming software is being dumbed down more and more because "we can take advantage of advances in computing power/performance". If I believe everything coming from MS, I would believe that businesses want to hire sub-par programmers who can't possibly deal with "low level details" like DB access. The MS message with .NET started out as a wonderful new platform for creating web applications and has grown into something that I'm less and less impressed with. The fundamental problem of storing data in a way that satisfies the needs of an application, the needs of reporting tools/systems, the need of end-users has not changed or been improved in any significant way. Instead, we seem to be trying to hide the hard facts with layers of code that slow things down, move programmers farther and farther away from solving fundamental problems and treats software development as a much simpler act than it really is. I guess the underlying belief is that the fundamental problem presented by relational databases will resolved soon and the capability to benefit from that fundamental change will already be in place. The practical impact of LINQ may well be the creation of more work for DB professionals, not less. The types of databases programmers create, particularly inexperienced programmers, are usually very poor designs that do not lend themselves to robustness in-terms of access requirements. They may work for the application developer, but custom reports and queries will likely be overly complicated and difficult to perform. Programmers will likely feel they can skimp on the DB design because the code is going to deal with things for them. For my personal uses at my current employer, the practical benefits of LINQ are fairly limited. The system we use is very dynamic and very few table names or structures are actually static. There are core system tables that provide key definitions, but much of the actual data storage that is needed for applications, reports, end-user queies is created on-demand based on the nature of the project being worked on. LINQ could be used, but I feel it would take much more code, not less. In the areas where tables names and structures are static, LINQ could be useful, but 1) I tyically don't like to build classes around DB schemas, 2) I don't like to have
-
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 quoted:
I've commented on why attributes are superior to attributes before
Typo? Or just a really unfortunate case of clashing nomenclature? ;P
Marc Clifton wrote:
I fundamentally disagree with creating classes to mirror the database schema
Isn't there a potentially fundamental difference in requirements here, between the code that builds the database and the code that queries the database? Or even between querying for the purpose of editing and the purpose of reporting?
----
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 quoted:
I've commented on why attributes are superior to attributes before
Typo? Or just a really unfortunate case of clashing nomenclature? ;P
Marc Clifton wrote:
I fundamentally disagree with creating classes to mirror the database schema
Isn't there a potentially fundamental difference in requirements here, between the code that builds the database and the code that queries the database? Or even between querying for the purpose of editing and the purpose of reporting?
----
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
Shog9 wrote:
Or even between querying for the purpose of editing and the purpose of reporting?
Yes, that's a good way of putting it. Marc