InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSun, 26 May 2013 00:09:35 GMT20http://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]wbrianwhite (11/4/2010)[/b][hr][quote][b]jyurich (11/3/2010)[/b][hr]Am I the only one using Microsoft's Entity Data Model (EDM) technology as an ORM for modeling as well as for the data access layer? This is a part of their new Entity Framework model introduced in .NET 3.5 SP1.I can tell you that for years we have both written our own code generation utilities as well as implemented 3rd party variations - and the MS version is by far the most superior from many perspectives.I highly encourage all of you SQL folks to start becoming very familiar with this, if you are not already.[url=http://msdn.microsoft.com/en-us/data/ef.aspx][/url]On a final note, while I don't agree with auto-generating databases, I do agree with standardizing on table structures with basic things like a primary keys, status fields and naming standards.RAP will not take foothold. Microsoft Entity Framework, however, has the full backing of Microsoft's neverending resources at its disposal :)[/quote]From the beginner's guide from the URL: "In fact, I've never before written a line of SQL, yet I was able to build a rich web application thanks to an ORM."That scares the bejeezus out of me. Again, agree completely. None of that matters in small apps, but small app shops don't tend to employ many SQLServerCentral readers.[/quote]The notion that anybody off the street can specify databases, yet wouldn't be allowed to code XYZ module without 10 years of experience with XYZ, puzzled me for quite a while. I ultimately came to the conclusion that coders, 1) have no real clue about data and 2) are terminally arrogant.Small apps, if any good, tends to become a Big App in due time. By then, it's "too much trouble" to clean up the mess. Spolsky still advocates (last I looked, anyway) Big Design Up Front; be optimistic that your small app will grow up to be a Big App and design accordingly. Think about the catalog first, don't just do a ByteDump and let the client code blot the ACID.Thu, 04 Nov 2010 08:27:22 GMTRobertYounghttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]jyurich (11/3/2010)[/b][hr]Am I the only one using Microsoft's Entity Data Model (EDM) technology as an ORM for modeling as well as for the data access layer? This is a part of their new Entity Framework model introduced in .NET 3.5 SP1.I can tell you that for years we have both written our own code generation utilities as well as implemented 3rd party variations - and the MS version is by far the most superior from many perspectives.I highly encourage all of you SQL folks to start becoming very familiar with this, if you are not already.[url=http://msdn.microsoft.com/en-us/data/ef.aspx][/url]On a final note, while I don't agree with auto-generating databases, I do agree with standardizing on table structures with basic things like a primary keys, status fields and naming standards.RAP will not take foothold. Microsoft Entity Framework, however, has the full backing of Microsoft's neverending resources at its disposal :)[/quote]From the beginner's guide from the URL: "In fact, I've never before written a line of SQL, yet I was able to build a rich web application thanks to an ORM."That scares the bejeezus out of me. "Whereas one database may require a String, another may require that it be called a VarChar. When using the EF, this minor annoyance is abstracted by the database provider."Right. Because companies are always switching out minor, unimportant stuff like their database vendor. What a useless feature. If a company is really switching from Windows+SQL Server they are probably switching to Linux + MySQL or Sun + Oracle. Neither of which would be in any way supported. Abstracting away database column types is like abstracting away the datatype of a variable. Would it be better for an application developer or worse to only have "number" instead of Int32, Int64, Float, etc. Worse. So why would it be better for a database developer? It is REALLY important to specify the right string datatype. If your ORM creates varchar and you need to support japanese characters that were only supported in Nvarchar, what do you do then? "Kamran22 Jul 2010 5:12 PMIt's important to note that it's still important to know SQL so you understand what is happening behind-the-scenes. If you don't, just as in LINQ-to-SQL, you could really mess up your app with unoptimized code.It's so hard to make things like this easy for a beginner yet introduce them to important concepts like concurrency and optimized queries."Exactly. What is EF doing when you save? When you read? What isolation level is used for reading? How can you tweak that for some cases where dirty read is allowable, and other cases where it's not? How do you begin/commit a transaction from entity framework code? How do you add error handling in the sql if the transaction failed?"Moni29 Sep 2010 3:23 AM...The whole premise of "ORMs help developers be more efficient and focused, since they don't need to spend brain cycles thinking about how to communicate with the database." is fundamentally flawed and incorrect. If you make an app you have to think about scalability and performance. In order to be aware of those issues you need to know about the SQL queries that are generated via EF and the underlying architecture. If you ignore that aspect then you'll have a serious problem sometime further in the development cycle....."Again, agree completely. None of that matters in small apps, but small app shops don't tend to employ many SQLServerCentral readers.Thu, 04 Nov 2010 08:08:54 GMTwbrianwhitehttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]jyurich (11/3/2010)[/b][hr]Am I the only one using Microsoft's Entity Data Model (EDM) technology as an ORM for modeling as well as for the data access layer? This is a part of their new Entity Framework model introduced in .NET 3.5 SP1.I can tell you that for years we have both written our own code generation utilities as well as implemented 3rd party variations - and the MS version is by far the most superior from many perspectives.I highly encourage all of you SQL folks to start becoming very familiar with this, if you are not already.[url=http://msdn.microsoft.com/en-us/data/ef.aspx][/url]On a final note, while I don't agree with auto-generating databases, I do agree with standardizing on table structures with basic things like a primary keys, status fields and naming standards.RAP will not take foothold. Microsoft Entity Framework, however, has the full backing of Microsoft's neverending resources at its disposal :)[/quote]I think that everyone is hopeful for the EF to be the main ORM for .NET developers. However, compared to several of the other ORMs, it has not matured enough to compete. Other ORM packages also provide different bells/whistles that otherwise would have needed to be completely written from scratch using L2S or EF. Now that can be debated ad nauseam, but I think the bottom line is for developers to feel comfortable with it. I think after another year or so, it will be used more widely.Thu, 04 Nov 2010 04:52:00 GMTron.buchanan.ushttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspxAm I the only one using Microsoft's Entity Data Model (EDM) technology as an ORM for modeling as well as for the data access layer? This is a part of their new Entity Framework model introduced in .NET 3.5 SP1.I can tell you that for years we have both written our own code generation utilities as well as implemented 3rd party variations - and the MS version is by far the most superior from many perspectives.I highly encourage all of you SQL folks to start becoming very familiar with this, if you are not already.[url=http://msdn.microsoft.com/en-us/data/ef.aspx][/url]On a final note, while I don't agree with auto-generating databases, I do agree with standardizing on table structures with basic things like a primary keys, status fields and naming standards.RAP will not take foothold. Microsoft Entity Framework, however, has the full backing of Microsoft's neverending resources at its disposal :)Wed, 03 Nov 2010 17:15:01 GMTjyurichhttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]wbrianwhite (11/2/2010)[/b][hr][quote][b]Jeff Moden (11/1/2010)[/b][hr][quote]Hi Brian... I know who David Ziffer is... he wrote the article. I've probably missed it in one of your posts on this thread but who are you, what is your relationship to RAP, and why are you answering for David Ziffer? No insult meant especially since it was a well put post above... I just want to know.[/quote]I wasn't answering for him, I was just thanking you for expressing my problem with RAP so succinctly.[/quote]Ah... got it. Thanks for the feedback, Brian.Tue, 02 Nov 2010 10:50:59 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]Jeff Moden (11/1/2010)[/b][hr][quote]Hi Brian... I know who David Ziffer is... he wrote the article. I've probably missed it in one of your posts on this thread but who are you, what is your relationship to RAP, and why are you answering for David Ziffer? No insult meant especially since it was a well put post above... I just want to know.[/quote]I wasn't answering for him, I was just thanking you for expressing my problem with RAP so succinctly.Tue, 02 Nov 2010 10:40:39 GMTwbrianwhitehttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]wbrianwhite (11/1/2010)[/b][hr][quote][b]RobertYoung (11/1/2010)[/b][hr][quote][b]wbrianwhite (11/1/2010)[/b][hr][quote][b]RobertYoung (10/31/2010)[/b][hr][quote][b]wbrianwhite (10/30/2010)[/b][hr][quote]All of the other techniques mentioned can built into a generator[/quote]I have a hard time believing this. How would a code generator know enough about your application structure, data size, and database performance to 'decide' now is the time to use an indexed view? CTEs can sometimes be used for performance, if you know which indexes are out there and are analyzing query plans of different approaches for a proc. Otherwise they're useful for code maintainability, which wouldn't be an issue in generated code. [/quote]The same way humans do: recognize the pattern. For CTE's, the most useful use is in traversing hierarchies in adjacency list form. Easy enough to recognize.[/quote]Really? How?I also use them for handling duplicate rows, and I've seen them used for server side paging as well.[/quote]If you mean CTE: http://blog.crowe.co.nz/blog/archive/2007/09/06/Microsoft-SQL-Server-2005---CTE-Example-of-a-simple.aspx[/quote]Yes... I'm quite familiar with CTEs. I am saying 'how will a generator recognize they should be used'? CRUD will never be aware of nested relationships or recursive self-joins. It just handles inserting one row, retrieving one row, etc.[/quote]The generator merely needs to know what the human knows: if a table contains SelfId and ParentId (or ChildId), then the table is, by definition, an adjacency list; and therefore is managed with a CTE process. Yes, the developer and the generator have to agree on what column names constitute Id; but the humans do too.Mon, 01 Nov 2010 20:42:22 GMTRobertYounghttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]wbrianwhite (11/1/2010)[/b][hr][quote][b]Jeff Moden (11/1/2010)[/b]Heh... there're a couple of dozen people on this site alone who are capable of pulling off huge multi-row inserts from a GUI via a stored procedure. If you'd care to throw some $$$ in their direction, I imagine they'd be happy to write the code for you.So far as the rest of it goes, I understand that your goal is very well intentioned and making it so developers don't actually need to think about such drudgery as writing insert code. But that's not a real change because a lot of them don't think of it as it is. Your product is an improvement for [i]them [/i]because you've perpetuated the notion that a developer doesn't actually have to think about the harm they may be causing to the database, the underlying server, or even the "pipe". You've also given them something to blame because you've also removed the responsibility. What would really be cool is if a product like this actually did something better than a developer... like figuring out the proper way to insert groups of rows. My apologies for how blunt that sounds but it would nice.[/quote]Thank you. RAP seems to have a procedural programmer's approach to a database currently. A database is treated as just a fancy version of storing things in a series of individual files on the web server. An insert of a group of rows is a single insert and should be treated as such to take advantage of the atomicity of transactions. Otherwise you need to recreate transactions in the app layer, which will simply never be as good. If for no other reason, that you could spend minutes inserting your rows before you get a failure 8500 records in, and by the time you go to delete all those rows someone has already reported on the data that was sitting in the database in a committed status. Heck, someone might have already done something to the data creating a FK to it, making it impossible to back out when you realize you need to. Perhaps RAP could accept a large xml string, and insert into tables in a set based way from that. I don't know how well that can be automated though. It's a fairly easy technique for passing in sets of data from a GUI as a set, even parent-child relationships.[/quote]Hi Brian... I know who David Ziffer is... he wrote the article. I've probably missed it in one of your posts on this thread but who are you, what is your relationship to RAP, and why are you answering for David Ziffer? No insult meant especially since it was a well put post above... I just want to know.Mon, 01 Nov 2010 19:51:53 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]RobertYoung (11/1/2010)[/b][hr][quote][b]wbrianwhite (11/1/2010)[/b][hr][quote][b]RobertYoung (10/31/2010)[/b][hr][quote][b]wbrianwhite (10/30/2010)[/b][hr][quote]All of the other techniques mentioned can built into a generator[/quote]I have a hard time believing this. How would a code generator know enough about your application structure, data size, and database performance to 'decide' now is the time to use an indexed view? CTEs can sometimes be used for performance, if you know which indexes are out there and are analyzing query plans of different approaches for a proc. Otherwise they're useful for code maintainability, which wouldn't be an issue in generated code. [/quote]The same way humans do: recognize the pattern. For CTE's, the most useful use is in traversing hierarchies in adjacency list form. Easy enough to recognize.[/quote]Really? How?I also use them for handling duplicate rows, and I've seen them used for server side paging as well.[/quote]If you mean CTE: http://blog.crowe.co.nz/blog/archive/2007/09/06/Microsoft-SQL-Server-2005---CTE-Example-of-a-simple.aspx[/quote]Yes... I'm quite familiar with CTEs. I am saying 'how will a generator recognize they should be used'? CRUD will never be aware of nested relationships or recursive self-joins. It just handles inserting one row, retrieving one row, etc.Mon, 01 Nov 2010 19:34:02 GMTwbrianwhitehttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]Jeff Moden (11/1/2010)[/b]Heh... there're a couple of dozen people on this site alone who are capable of pulling off huge multi-row inserts from a GUI via a stored procedure. If you'd care to throw some $$$ in their direction, I imagine they'd be happy to write the code for you.So far as the rest of it goes, I understand that your goal is very well intentioned and making it so developers don't actually need to think about such drudgery as writing insert code. But that's not a real change because a lot of them don't think of it as it is. Your product is an improvement for [i]them [/i]because you've perpetuated the notion that a developer doesn't actually have to think about the harm they may be causing to the database, the underlying server, or even the "pipe". You've also given them something to blame because you've also removed the responsibility. What would really be cool is if a product like this actually did something better than a developer... like figuring out the proper way to insert groups of rows. My apologies for how blunt that sounds but it would nice.[/quote]Thank you. RAP seems to have a procedural programmer's approach to a database currently. A database is treated as just a fancy version of storing things in a series of individual files on the web server. An insert of a group of rows is a single insert and should be treated as such to take advantage of the atomicity of transactions. Otherwise you need to recreate transactions in the app layer, which will simply never be as good. If for no other reason, that you could spend minutes inserting your rows before you get a failure 8500 records in, and by the time you go to delete all those rows someone has already reported on the data that was sitting in the database in a committed status. Heck, someone might have already done something to the data creating a FK to it, making it impossible to back out when you realize you need to. Perhaps RAP could accept a large xml string, and insert into tables in a set based way from that. I don't know how well that can be automated though. It's a fairly easy technique for passing in sets of data from a GUI as a set, even parent-child relationships.Mon, 01 Nov 2010 19:31:23 GMTwbrianwhitehttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]David Ziffer (11/1/2010)[/b][hr][quote][b]Jeff Moden (10/31/2010)[/b][hr][quote][b]David Ziffer (10/30/2010)[/b][hr]I certainly would load rows into a single table as a group, but even those insertions must be done through individual calls to the RAP insertion procedure.[/quote]... If you need to insert a "group" of rows, it just shouldn't be done one row at a time. As with anything else, "It Depends" but, comparatively speaking, it's much too resource intensive to insert groups of rows in a RBAR fashion. It would be really cool if your product knew how to receive and insert more than one row in a set based fashion.[/quote]Jeff: I agree with you and I just haven't had the time how to figure out now to more efficiently do multiple-row insertions yet. Perhaps this will be a future improvement. For the moment, the single-row implementation does serve as an example of how to simultaneously update a "current" and "archive" table.With regards to RBAR: it may be true that my current implementation of RAP does cause agony for the computer, which must handle insertions at the row level. However the "A" in RBAR suggests that there is perhaps a human who is in agony somewhere. One of the main points of RAP is that the programmer [b]doesn't have to think about any of this stuff at all[/b]. At the application level, the programmer just says to RAP's ORM: "write whatever you have." The programmer doesn't think about rows or columns or even tables. In fact, the programmer doesn't have to care about implementation at all (unless of course RAP is too slow for him and we are forced to start programming for more efficiency).My main purpose here is to illustrate what can be done from a functional perspective, if only we would all stop thinking at the component level and start implementing consistently at the system level. I do not presume that the algorithms I present here are the most efficient possible and I am happy for people's suggestions as to how I might improve RAP at any level - because I do want it to be used in real production systems.So I thank you for your input and I will almost certainly look into this issue. But once again, the point here is to throw down some sort of prototype for doing things systematically.[/quote]Heh... there're a couple of dozen people on this site alone who are capable of pulling off huge multi-row inserts from a GUI via a stored procedure. If you'd care to throw some $$$ in their direction, I imagine they'd be happy to write the code for you.So far as the rest of it goes, I understand that your goal is very well intentioned and making it so developers don't actually need to think about such drudgery as writing insert code. But that's not a real change because a lot of them don't think of it as it is. Your product is an improvement for [i]them [/i]because you've perpetuated the notion that a developer doesn't actually have to think about the harm they may be causing to the database, the underlying server, or even the "pipe". You've also given them something to blame because you've also removed the responsibility. What would really be cool is if a product like this actually did something better than a developer... like figuring out the proper way to insert groups of rows. My apologies for how blunt that sounds but it would nice.Mon, 01 Nov 2010 19:08:07 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]wbrianwhite (11/1/2010)[/b][hr][quote][b]RobertYoung (10/31/2010)[/b][hr][quote][b]wbrianwhite (10/30/2010)[/b][hr][quote]All of the other techniques mentioned can built into a generator[/quote]I have a hard time believing this. How would a code generator know enough about your application structure, data size, and database performance to 'decide' now is the time to use an indexed view? CTEs can sometimes be used for performance, if you know which indexes are out there and are analyzing query plans of different approaches for a proc. Otherwise they're useful for code maintainability, which wouldn't be an issue in generated code. [/quote]The same way humans do: recognize the pattern. For CTE's, the most useful use is in traversing hierarchies in adjacency list form. Easy enough to recognize.[/quote]Really? How?I also use them for handling duplicate rows, and I've seen them used for server side paging as well.[/quote]If you mean CTE: http://blog.crowe.co.nz/blog/archive/2007/09/06/Microsoft-SQL-Server-2005---CTE-Example-of-a-simple.aspxMon, 01 Nov 2010 12:11:45 GMTRobertYounghttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]RobertYoung (10/31/2010)[/b][hr][quote][b]wbrianwhite (10/30/2010)[/b][hr][quote]All of the other techniques mentioned can built into a generator[/quote]I have a hard time believing this. How would a code generator know enough about your application structure, data size, and database performance to 'decide' now is the time to use an indexed view? CTEs can sometimes be used for performance, if you know which indexes are out there and are analyzing query plans of different approaches for a proc. Otherwise they're useful for code maintainability, which wouldn't be an issue in generated code. [/quote]The same way humans do: recognize the pattern. For CTE's, the most useful use is in traversing hierarchies in adjacency list form. Easy enough to recognize.[/quote]Really? How?I also use them for handling duplicate rows, and I've seen them used for server side paging as well.Mon, 01 Nov 2010 11:29:34 GMTwbrianwhitehttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]Jeff Moden (10/31/2010)[/b][hr][quote][b]David Ziffer (10/30/2010)[/b][hr]I certainly would load rows into a single table as a group, but even those insertions must be done through individual calls to the RAP insertion procedure.[/quote]... If you need to insert a "group" of rows, it just shouldn't be done one row at a time. As with anything else, "It Depends" but, comparatively speaking, it's much too resource intensive to insert groups of rows in a RBAR fashion. It would be really cool if your product knew how to receive and insert more than one row in a set based fashion.[/quote]Jeff: I agree with you and I just haven't had the time how to figure out now to more efficiently do multiple-row insertions yet. Perhaps this will be a future improvement. For the moment, the single-row implementation does serve as an example of how to simultaneously update a "current" and "archive" table.With regards to RBAR: it may be true that my current implementation of RAP does cause agony for the computer, which must handle insertions at the row level. However the "A" in RBAR suggests that there is perhaps a human who is in agony somewhere. One of the main points of RAP is that the programmer [b]doesn't have to think about any of this stuff at all[/b]. At the application level, the programmer just says to RAP's ORM: "write whatever you have." The programmer doesn't think about rows or columns or even tables. In fact, the programmer doesn't have to care about implementation at all (unless of course RAP is too slow for him and we are forced to start programming for more efficiency).My main purpose here is to illustrate what can be done from a functional perspective, if only we would all stop thinking at the component level and start implementing consistently at the system level. I do not presume that the algorithms I present here are the most efficient possible and I am happy for people's suggestions as to how I might improve RAP at any level - because I do want it to be used in real production systems.So I thank you for your input and I will almost certainly look into this issue. But once again, the point here is to throw down some sort of prototype for doing things systematically.Mon, 01 Nov 2010 09:01:19 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]Jeff Moden (10/31/2010)[/b][hr][quote][b]David Ziffer (10/30/2010)[/b][hr]I certainly would load rows into a single table as a group, but even those insertions must be done through individual calls to the RAP insertion procedure.[/quote]I'm not trying to be a smart guy here. Just an opinion on my part. What you've stated above is part of the reason why I don't use such procedures. If you need to insert a "group" of rows, it just shouldn't be done one row at a time. As with anything else, "It Depends" but, comparatively speaking, it's much too resource intensive to insert groups of rows in a RBAR fashion. It would be really cool if your product knew how to receive and insert more than one row in a set based fashion.[/quote]I'm not 100% sure, butI _think_ I have already mentioned that I'd prefer the logic for auditing and keeping history to be placed in a trigger instead of stored procedures. And Jeff's argument is one of the two major reasons why I favor that approach. (The other one being that a trigger is much harder to circumvent than a CRUD procedure).And especially with a completely generated framework, there is (IMO) little reason NOT to choose for triggers. The development of a potentially complex trigger and the extensive testing is only required once.Mon, 01 Nov 2010 01:46:29 GMTHugo Kornelishttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]David Ziffer (10/30/2010)[/b][hr]I certainly would load rows into a single table as a group, but even those insertions must be done through individual calls to the RAP insertion procedure.[/quote]I'm not trying to be a smart guy here. Just an opinion on my part. What you've stated above is part of the reason why I don't use such procedures. If you need to insert a "group" of rows, it just shouldn't be done one row at a time. As with anything else, "It Depends" but, comparatively speaking, it's much too resource intensive to insert groups of rows in a RBAR fashion. It would be really cool if your product knew how to receive and insert more than one row in a set based fashion.Sun, 31 Oct 2010 23:11:43 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]David Ziffer (10/30/2010)[/b][hr]Even if they were all inserted with a single statement, it is not clear that a "datetime" performed for each row would produce an identical value in each row.[/quote]Datetime is only calculated once per query so no worries there.Sun, 31 Oct 2010 22:53:30 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]RobertYoung (10/31/2010)[/b][hr][quote][b]wbrianwhite (10/30/2010)[/b][hr][quote]All of the other techniques mentioned can built into a generator[/quote]I have a hard time believing this. How would a code generator know enough about your application structure, data size, and database performance to 'decide' now is the time to use an indexed view? CTEs can sometimes be used for performance, if you know which indexes are out there and are analyzing query plans of different approaches for a proc. Otherwise they're useful for code maintainability, which wouldn't be an issue in generated code. [/quote]The same way humans do: recognize the pattern. For CTE's, the most useful use is in traversing hierarchies in adjacency list form. Easy enough to recognize.[/quote]Robert is right on this one. That's why we focus on the database design, which also considers the ORM that we generate. We know that unique constraints, indexes, and foreign keys will all be seen by the ORM generator, and so optimizing the retrieval process. Like I said, we don't look for the ORM to do anything but generate the plumbing to get the data in and out of the database and into objects, nothing more. The trick with the ORM, and especially generated ORMs, is to know which ORM does what and every extent of their capabilites, developer productivity increase, etc. Expecting the ORM generator to do everything for you, I believe, is naive.Sun, 31 Oct 2010 16:03:08 GMTron.buchanan.ushttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]wbrianwhite (10/30/2010)[/b][hr][quote]All of the other techniques mentioned can built into a generator[/quote]I have a hard time believing this. How would a code generator know enough about your application structure, data size, and database performance to 'decide' now is the time to use an indexed view? CTEs can sometimes be used for performance, if you know which indexes are out there and are analyzing query plans of different approaches for a proc. Otherwise they're useful for code maintainability, which wouldn't be an issue in generated code. [/quote]The same way humans do: recognize the pattern. For CTE's, the most useful use is in traversing hierarchies in adjacency list form. Easy enough to recognize.Sun, 31 Oct 2010 13:53:30 GMTRobertYounghttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]Jeff Moden (10/30/2010)[/b][hr]First, I whole-heartedly agree with the principle of storing the same AuditDate when adding a "group" of rows for the very reason stated. To wit, my question would be, why would you add a group of rows one row at a time instead of loading them as a complete set with a single insert?[/quote]I certainly would load rows into a single table as a group, but even those insertions must be done through individual calls to the RAP insertion procedure. So even though they are queued and streamed, they are still done with individual stored procedure calls. Even if they were all inserted with a single statement, it is not clear that a "datetime" performed for each row would produce an identical value in each row.Then of course there is the fact that most writes to the database do not involve merely a single table. If I write a parent and child record together and I expect to retreive them together, they'd better have the same AuditDate on them.Sat, 30 Oct 2010 20:39:42 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote]All of the other techniques mentioned can built into a generator[/quote]I have a hard time believing this. How would a code generator know enough about your application structure, data size, and database performance to 'decide' now is the time to use an indexed view? CTEs can sometimes be used for performance, if you know which indexes are out there and are analyzing query plans of different approaches for a proc. Otherwise they're useful for code maintainability, which wouldn't be an issue in generated code. I have seen several systems come out that can build up medium/medium-low complexity applications automatically. But none that would work for a large software as a service type company. I think in the attempt the company would spend most of their time developing the tool to do what they want, making it ever more customized to a specific domain, and making the dev work be at one or two removes from where it really needs to be. To include indexed views you'd need to program an entire framework for the concept, which seems quite difficult in a CRUD oriented system, verify it doesn't mess anything else up in the whole generator, and then you'd still need someone inputting data about your load and data size and all the other reasons that would lead you to use an indexed view, each time that you want such a view. Which wouldn't end up cutting much time off the process of adding one.Sat, 30 Oct 2010 19:16:25 GMTwbrianwhitehttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]Jeff Moden (10/30/2010)[/b][hr]@David ZifferI have a question based on the following snippet from the article...First, I whole-heartedly agree with the principle of storing the same AuditDate when adding a "group" of rows for the very reason stated. To wit, my question would be, why would you add a group of rows one row at a time instead of loading them as a complete set with a single insert?[/quote]I would think that's all that an automated code generator type tool can do, even though it is not the right approach from a database perspective. Inserting as a set would be better in every way: atomic, can be controlled by a transaction with commit/rollback logic, the whole set will go in at once meaning for the batch of data being inserted it will be much less intensive for transaction logging, row/page/schema locking, you can select from two tables joined together into 2 other tables instead of copying one row, looking up a new id, copying the depndent row, and probably 10 other things that don't come to mind right now. Which is why I find the insistence that doing it the tool's way is the only way. I've never worked with Ruby on Rails, but from every serious developer I've read who's written about it, the Rails toolkit is enough to get you going, but you eventually end up with custom code when you need to address real world complex problems. Losing the ability to regenerate your code base all over, but gaining the rather important ability to meet your customers' needs.Sat, 30 Oct 2010 19:04:31 GMTwbrianwhitehttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx@David ZifferI have a question based on the following snippet from the article...[quote]The reader may question why the application should pass the audit date at all; why not just have each insertion routine internally get the current date from the database and put that value in this field? The answer has to do with auditing. The reason we store the AuditDate at all is to retrieve historical data from the archive tables. [font="Arial Black"]If a set of records is being written (added, updated, deleted) as a group, then we need to be able to retrieve them as a group.[/font] In order to ensure that all records written together are also retrieved together, they must all have precisely the same AuditDate. Therefore we cannot leave it to the individual insertion routines (for each table) to each supply AuditDates on the fly. Instead, the application must generate a single date to be used on absolutely every record involved in a given transaction.[/quote]First, I whole-heartedly agree with the principle of storing the same AuditDate when adding a "group" of rows for the very reason stated. To wit, my question would be, why would you add a group of rows one row at a time instead of loading them as a complete set with a single insert?Sat, 30 Oct 2010 09:13:32 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]RobertYoung (10/29/2010)[/b][hr][quote][b]ron.buchanan.us (10/29/2010)[/b][hr][quote][b]careusa2003 (10/29/2010)[/b][hr]I would not touch this design with a 10-foot pole.[/quote]If you are going to insult a design of which you know little about, at least elaborate. I would love to know what it is that you find so horrible about the design.[/quote]The only vector which makes sense: s/he's a client-side coder who lives by the mantra "we prefer to enforce constraints in our application code". Known lots o such folks. They make messes worse than a puppy. :w00t:[/quote]And now insults are simply being traded. Stop this crap folks. If you're going to claim that you wouldn't "touch this design with a 10-foot pole" or that something will "make messes worse than a puppy", back up your claim with code, links to white papers, or write a good explanation as to why. Just stop with the non-substantive attacks. ;-)Sat, 30 Oct 2010 08:58:24 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]David Ziffer (10/29/2010)[/b][hr][quote][b]RobertYoung (10/29/2010)[/b][hr]And do you have terabyte+ data because someone never bothered with defining normalized data? Are you doing text processing? [b]There is no de-normalize for performance. It doesn't require much skill to do a bytedump into a database.[/b] Been there, seen that. Got fired a few times for complaining; that's OK, who wants to work with knuckleheads? ... The fact that you *need* lots o sql gyrations is prima fascia evidence that the schema is wonky.As Phil (not Factor) used to say: "in the old days it was simple data and complex code, now it's complex data and simple code". What he meant by "complex data" was fully normal. If one wishes to continue to create applications of bloated code manipulating simple as dirt bytedumps, then fine. But that approach is not a database approach; one may use some sql along the way, but it still isn't an example of the Relational Model incarnate.[/quote]Thank you, thank you RobertYoung for supporting this position. I was beginning to think I was crazy for being almost the only person I know who subscribes to it.I have never EVER seen a low-normalization database that wasn't a disaster. Not only that, I have never met people who maintained such a database who actually realized what a mess their data was in. Which of course explains how it is that they can tolerate the mess and the endless problems it creates (they actually think they're doing the best that can be done).Denormalizing a normalized database is trivial. Maintaining a denormalized database is, simply, impossible. And if you think that you're reasonably maintaining one, might I suggest that you're in that most hopeless category of people: those who don't even know what it is that they don't know.Apparently, Father [still] Knows Best.[/quote]By denormalized I just meant storing company id on relevant rows, when company id can never change on a transaction. It's denormalized, but it's not a maintenance issue. The performance boost is completely worth it.Sat, 30 Oct 2010 08:41:34 GMTwbrianwhitehttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote]And do you have terabyte+ data because someone never bothered with defining normalized data? Are you doing text processing? There is no de-normalize for performance. It doesn't require much skill to do a bytedump into a database. Been there, seen that. Got fired a few times for complaining; that's OK, who wants to work with knuckleheads? BCNF datastores can be implemented efficiently either on arrays of short strokes or SSDs; and yields maximum global efficiency (coders tend to say things like, "my query ran faster in [MySql|VSAM|dBaseII] than SQLServer", blissfully ignoring all that client side manipulation and ACID services that MySql doesn't provide) since the client code does so much less. BCNF also gives you maximum flexibility, the xml folks and their "hierarchical model" notwithstanding; adding columns/tables has so few side effects compared to doing the same in xml. The fact that you *need* lots o sql gyrations is prima fascia evidence that the schema is wonky.As Phil (not Factor) used to say: "in the old days it was simple data and complex code, now it's complex data and simple code". What he meant by "complex data" was fully normal. If one wishes to continue to create applications of bloated code manipulating simple as dirt bytedumps, then fine. But that approach is not a database approach; one may use some sql along the way, but it still isn't an example of the Relational Model incarnate.All of the other techniques mentioned can built into a generator; whether RAP ever does is a separate question. Don't conflate RAP, per se, with generation as a technique.I'm not asserting that RAP is either perfect or the generation implementation I would build were I to do so. But it is fundamentally the correct Yellow Brick Road.[/quote]No, we have lots of data because there are millions and millions of transactions and users in a single database. We're in the process of moving large chunks of data into other database servers grouped by customer. But our main database is large because there's lots of data, not because it's poorly designed. "There is no de-normalize for performance."Of course there is. If you need to limit a select to only rows relevant to a particular company the query is much more efficient if the company id is just stored on those rows, instead of having to join through four or five tables to get back to company id if it was fully normalized. You can index the company field and then your query just does a simple index seek.Sat, 30 Oct 2010 08:39:00 GMTwbrianwhitehttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]RobertYoung (10/29/2010)[/b][hr]And do you have terabyte+ data because someone never bothered with defining normalized data? Are you doing text processing? [b]There is no de-normalize for performance. It doesn't require much skill to do a bytedump into a database.[/b] Been there, seen that. Got fired a few times for complaining; that's OK, who wants to work with knuckleheads? ... The fact that you *need* lots o sql gyrations is prima fascia evidence that the schema is wonky.As Phil (not Factor) used to say: "in the old days it was simple data and complex code, now it's complex data and simple code". What he meant by "complex data" was fully normal. If one wishes to continue to create applications of bloated code manipulating simple as dirt bytedumps, then fine. But that approach is not a database approach; one may use some sql along the way, but it still isn't an example of the Relational Model incarnate.[/quote]Thank you, thank you RobertYoung for supporting this position. I was beginning to think I was crazy for being almost the only person I know who subscribes to it.I have never EVER seen a low-normalization database that wasn't a disaster. Not only that, I have never met people who maintained such a database who actually realized what a mess their data was in. Which of course explains how it is that they can tolerate the mess and the endless problems it creates (they actually think they're doing the best that can be done).Denormalizing a normalized database is trivial. Maintaining a denormalized database is, simply, impossible. And if you think that you're reasonably maintaining one, might I suggest that you're in that most hopeless category of people: those who don't even know what it is that they don't know.Apparently, Father [still] Knows Best.Fri, 29 Oct 2010 22:57:56 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]wbrianwhite (10/29/2010)[/b][hr][quote][b]RobertYoung (10/29/2010)[/b][hr][quote][b]ron.buchanan.us (10/29/2010)[/b][hr][quote][b]careusa2003 (10/29/2010)[/b][hr]I would not touch this design with a 10-foot pole.[/quote]If you are going to insult a design of which you know little about, at least elaborate. I would love to know what it is that you find so horrible about the design.[/quote]The only vector which makes sense: s/he's a client-side coder who lives by the mantra "we prefer to enforce constraints in our application code". Known lots o such folks. They make messes worse than a puppy. :w00t:[/quote]Or they have a terabyte+ database where the important procs need to be specifically tuned to be fast enough. RAP would replace your laboriously tuned proc with a vanilla CRUD one as soon as you add a column to the schema. That is my number one problem with all code generation systems or ORM systems, they just would never perform well in a really large environment. To go back the Industrial Revolution type metaphors... robots today do a lot of the assembly work on a Ford Focus. But how much of the space shuttle was assembled by robots? The really complex still requires skilled human assemblers.How often do RAP procs make use of CTEs? How often does RAP created indexed views? Does RAP ever use dynamic sql for when you want to shift indexes based on input parameters? How does RAP deal with distributed inserts where a chain of dependent inserts into tables all have to succeed or fail as one? When will RAP de-normalize for performance? I don't know of any tool that would do that, and where I work those are all needed.[/quote]And do you have terabyte+ data because someone never bothered with defining normalized data? Are you doing text processing? There is no de-normalize for performance. It doesn't require much skill to do a bytedump into a database. Been there, seen that. Got fired a few times for complaining; that's OK, who wants to work with knuckleheads? BCNF datastores can be implemented efficiently either on arrays of short strokes or SSDs; and yields maximum global efficiency (coders tend to say things like, "my query ran faster in [MySql|VSAM|dBaseII] than SQLServer", blissfully ignoring all that client side manipulation and ACID services that MySql doesn't provide) since the client code does so much less. BCNF also gives you maximum flexibility, the xml folks and their "hierarchical model" notwithstanding; adding columns/tables has so few side effects compared to doing the same in xml. The fact that you *need* lots o sql gyrations is prima fascia evidence that the schema is wonky.As Phil (not Factor) used to say: "in the old days it was simple data and complex code, now it's complex data and simple code". What he meant by "complex data" was fully normal. If one wishes to continue to create applications of bloated code manipulating simple as dirt bytedumps, then fine. But that approach is not a database approach; one may use some sql along the way, but it still isn't an example of the Relational Model incarnate.All of the other techniques mentioned can built into a generator; whether RAP ever does is a separate question. Don't conflate RAP, per se, with generation as a technique.I'm not asserting that RAP is either perfect or the generation implementation I would build were I to do so. But it is fundamentally the correct Yellow Brick Road.Fri, 29 Oct 2010 13:09:53 GMTRobertYounghttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote]Or they have a terabyte+ database where the important procs need to be specifically tuned to be fast enough. RAP would replace your laboriously tuned proc with a vanilla CRUD one as soon as you add a column to the schema. That is my number one problem with all code generation systems or ORM systems, they just would never perform well in a really large environment. To go back the Industrial Revolution type metaphors... robots today do a lot of the assembly work on a Ford Focus. But how much of the space shuttle was assembled by robots? The really complex still requires skilled human assemblers.How often do RAP procs make use of CTEs? How often does RAP created indexed views? Does RAP ever use dynamic sql for when you want to shift indexes based on input parameters? How does RAP deal with distributed inserts where a chain of dependent inserts into tables all have to succeed or fail as one? When will RAP de-normalize for performance? I don't know of any tool that would do that, and where I work those are all needed.[/quote]That is a valid point. However, just because there is a generated ORM, and one that reacts to the metadata of the DB, doesn't mean it is a poor choice for the administration portion of an application or for the simple CRUD. That, IMO, is the very purpose of using an ORM. Now, to have a facade or adapter layer between the custom application and any third-party, again IMO, is good design.We house large amounts of data. However, we also have an ORM sitting on top of that data. The difference is we are smart about how we query the data, the structure of the database, and what we use the ORM for. We never use the GetAll() methods, we only use the GetPaged() or GetByKey() methods. These are no different than doing a stored proc that is optimized because we have optimized the SQL ourselves. We can also customize the SQL for the queries, or just call a stored procedure; we are not bound by the the ORM, it is flexible.Because we are an enterprise environment, we took a while to make the decisions we made. We ran performance tests with different ORMs, and we also have designed the DBs in a way to serve their specific purpose. For instance, we have a reporting database that is denormalized and population occurs on job schedules with SSIS. We have the raw data where the data can be edited that feeds the reporting DB. We also have SSIS jobs that run regularly to feed data into the raw DBs from outside sources.Now, our ORM is NetTiers and not RAP. I wanted to point that out because you directly addressed RAP.Fri, 29 Oct 2010 12:22:55 GMTron.buchanan.ushttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]RobertYoung (10/29/2010)[/b][hr][quote][b]ron.buchanan.us (10/29/2010)[/b][hr][quote][b]careusa2003 (10/29/2010)[/b][hr]I would not touch this design with a 10-foot pole.[/quote]If you are going to insult a design of which you know little about, at least elaborate. I would love to know what it is that you find so horrible about the design.[/quote]The only vector which makes sense: s/he's a client-side coder who lives by the mantra "we prefer to enforce constraints in our application code". Known lots o such folks. They make messes worse than a puppy. :w00t:[/quote]Or they have a terabyte+ database where the important procs need to be specifically tuned to be fast enough. RAP would replace your laboriously tuned proc with a vanilla CRUD one as soon as you add a column to the schema. That is my number one problem with all code generation systems or ORM systems, they just would never perform well in a really large environment. To go back the Industrial Revolution type metaphors... robots today do a lot of the assembly work on a Ford Focus. But how much of the space shuttle was assembled by robots? The really complex still requires skilled human assemblers.How often do RAP procs make use of CTEs? How often does RAP created indexed views? Does RAP ever use dynamic sql for when you want to shift indexes based on input parameters? How does RAP deal with distributed inserts where a chain of dependent inserts into tables all have to succeed or fail as one? When will RAP de-normalize for performance? I don't know of any tool that would do that, and where I work those are all needed.Fri, 29 Oct 2010 11:12:40 GMTwbrianwhitehttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]ron.buchanan.us (10/29/2010)[/b][hr][quote][b]careusa2003 (10/29/2010)[/b][hr]I would not touch this design with a 10-foot pole.[/quote]If you are going to insult a design of which you know little about, at least elaborate. I would love to know what it is that you find so horrible about the design.[/quote]The only vector which makes sense: s/he's a client-side coder who lives by the mantra "we prefer to enforce constraints in our application code". Known lots o such folks. They make messes worse than a puppy. :w00t:Fri, 29 Oct 2010 07:50:48 GMTRobertYounghttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]careusa2003 (10/29/2010)[/b][hr]I would not touch this design with a 10-foot pole.[/quote]If you are going to insult a design of which you know little about, at least elaborate. I would love to know what it is that you find so horrible about the design.Fri, 29 Oct 2010 07:32:05 GMTron.buchanan.ushttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspxI would not touch this design with a 10-foot pole.Fri, 29 Oct 2010 05:56:35 GMTcareusa2003http://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]RobertYoung (10/27/2010)[/b][hr][quote][b]doofledorfer (10/27/2010)[/b][hr]CRUD-driven apps are in my experience a UI disaster.[/quote]The display of the UI isn't a function of CRUD-drivenness. All apps are CRUD. Most UI's today are rehashes of character graphics tools like Professional BASIC (and the 3270 long before). The widgets are still pixelated analogs of, well analog, car radio interfaces and Chinese restaurants. Radio sets, check boxes, lists, menus; there are even Dashboards with pixelated knobs and dials, for crying out loud. The sad fact is, there isn't much that's new in business/PC based software. Some of the devices from Apple have implemented new-ish gadgets, but those devices (yet) aren't integrated into business software. The iPad is likely to be the first; although tablets, per se, have been used in warehouse/distribution VAR systems for decades.Some object that generated CRUD means: BCNF datastores with limited data per interaction, rather than the flood of hundreds of "fields" which replicate the un-normalized messes so beloved by java/C#/VB coders (and COBOL/VSAM forebears; this genealogy mostly unknown to contemporary coders). Phones/Pads will demand more parsimonious data structures in order for applications to succeed; no keyboard and such. What form the UI takes is dependent on the generator, only; not the schema. It could be VB or html/js/AJAX or iPad or foobar, for all that it matters. BCNF datastores offer *more* flexibility in the display of data than the un-normalized alternatives; since the datastore is by definition fully disaggregated, the UI has the option of aggregating back to whatever level of mess the users demand. They will never know the difference, only that shipping inconsistent data is well nigh impossible.We need to keep a number of distinctions in mind: the discipline of RAP, the discipline of BCNF/5NF, data logic rather than code logic, server-side rather than client-side control, the UI. There are synergies and antagonisms at work here.[/quote]I had listed this in a previous post. We use NetTiers with CodeSmith. It is an incredible generator for an ORM. Our team focuses on the design of the DB, business rules, and UI. The generator gives us the plumbing, but we write all of the other parts ourselves. It will generate a web UI, mainly for testing or getting some test data into the database. It is a well thought out ORM.If we need to change the DB design, we write the SQL code to make the change and put it in the deployment document. We then regenerate to get the changes, and refactor our code where appropriate. Usually, we have a domain library with POCO's and the repository pattern to act as a facade to the ORM. It works well, and we use it in enterprise projects without a problem. In fact, it has saved countless hours of monotonous coding.Thu, 28 Oct 2010 06:01:44 GMTron.buchanan.ushttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]David Ziffer (10/27/2010)[/b][hr][quote][b]Bob the Mushroom (10/27/2010)[/b][hr]Hi David,How configurable are the object names? I know that it's initially unlikely anyone will bother to look into the database if it's getting auto-generated, but auto-generation isn't necessarily an excuse for failing to meet coding guidelines. Anyone who works with me and creates a stored procedure called SPTBadmUser_Delete is going to get it in the neck pretty quickly - exactly the same as any developer who creates a DataSet variable using a ds- prefix. YMMV, but in my opinion UserDelete gets the point across perfectly succinctly, possibly more rapidly for a human reader. I don't need the name to reflect the fact that it's a stored procedure that acts on a table, just the object being modified and the action being performed on it.[/quote]Right now RAP is pretty tied to its object name conventions. RAP is delivered in source form so of course if you were inclined you could change its conventions. But as for getting rid of the naming conventions entirely, I wish you luck.For example, what is "UserDelete"? It makes perfect sense if you already know what it is, but does everyone know what it is? My schema might contain a table called "UserDelete". Or "UserDelete" might be a stored procedure. Probably it isn't a function (because functions can't modify data) but what about "UserFetch"? Is that a function or a stored procedure? Or is that a table too?Systematic code generation requires totally unambiguous naming conventions. If you try to create a code generator without using a RAP-like system of being totally unambigouous, I predict you'll end up with users who are generating identical names for different objects. In RAP, the odds of doing this are precisely - zero.[/quote]Long time ago, maybe five years ;), I've used prefixes for my objects like usp_ or p_, but in nowadays I never had any problem with UserDelete. If you have some naming rules then you will not have to define table UserDelete, at least i will not have. So totally disagree with you. To name a procedure with prefix 'SPTBadm' is something that deserves more than what Bob mentioned. Glad that you didn't say anything about my comments for code style.You get us wrong, your article have great idea behind, and was pleasure to read it.Thu, 28 Oct 2010 01:40:23 GMTBoban Stojanovski-455883http://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]doofledorfer (10/27/2010)[/b][hr]To repeat what others have said, this has been done over and over.The thing that makes me most nervous though is how it turns the userinterface into a big table maintenance exercise for the databasedevelopers; and it's hard to think of any reasonable user storythat comes out looking like maintaining tables. CRUD-driven appsare in my experience a UI disaster.[/quote]doofledorfer: RAP does not derive a UI from the underlying schema. It generates code only as far up as the data layer.The business rules, as will be covered in a future article, are hand-written, as is the UI. However the business rules use a strict set of templates that reduce unnecessary variation in the business layer. The implementer is free to transform the data any way he/she wants in the business rules layer. Therefore RAP places absolutely no restrictions on the nature or even the content of the UI. In fact, RAP doesn't even presume that a human-readable UI even exists (you could just as well be building a web service). Although RAP comes with a demo that has a UI that mimics the underlying table structure, this is in no way a requirement.The benefit that RAP delivers in its upper levels is that it provides a prototype for a strict MVC pattern. Basically, all business logic and data transformation is done in the business rules layer. Implementers stricly avoid the encoding of any business logic at all in the UI. This makes RAP applications non-UI dependent, i.e. no matter what UI or set of UIs you decide to implement, they get their data from precisely the same underlying business rule structure. Once again, the same themes: consistency, commonality, and miminal code via systematic design.Wed, 27 Oct 2010 19:01:47 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]doofledorfer (10/27/2010)[/b][hr]CRUD-driven apps are in my experience a UI disaster.[/quote]The display of the UI isn't a function of CRUD-drivenness. All apps are CRUD. Most UI's today are rehashes of character graphics tools like Professional BASIC (and the 3270 long before). The widgets are still pixelated analogs of, well analog, car radio interfaces and Chinese restaurants. Radio sets, check boxes, lists, menus; there are even Dashboards with pixelated knobs and dials, for crying out loud. The sad fact is, there isn't much that's new in business/PC based software. Some of the devices from Apple have implemented new-ish gadgets, but those devices (yet) aren't integrated into business software. The iPad is likely to be the first; although tablets, per se, have been used in warehouse/distribution VAR systems for decades.Some object that generated CRUD means: BCNF datastores with limited data per interaction, rather than the flood of hundreds of "fields" which replicate the un-normalized messes so beloved by java/C#/VB coders (and COBOL/VSAM forebears; this genealogy mostly unknown to contemporary coders). Phones/Pads will demand more parsimonious data structures in order for applications to succeed; no keyboard and such. What form the UI takes is dependent on the generator, only; not the schema. It could be VB or html/js/AJAX or iPad or foobar, for all that it matters. BCNF datastores offer *more* flexibility in the display of data than the un-normalized alternatives; since the datastore is by definition fully disaggregated, the UI has the option of aggregating back to whatever level of mess the users demand. They will never know the difference, only that shipping inconsistent data is well nigh impossible.We need to keep a number of distinctions in mind: the discipline of RAP, the discipline of BCNF/5NF, data logic rather than code logic, server-side rather than client-side control, the UI. There are synergies and antagonisms at work here.Wed, 27 Oct 2010 17:56:02 GMTRobertYounghttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspxTo repeat what others have said, this has been done over and over.The thing that makes me most nervous though is how it turns the userinterface into a big table maintenance exercise for the databasedevelopers; and it's hard to think of any reasonable user storythat comes out looking like maintaining tables. CRUD-driven appsare in my experience a UI disaster.Wed, 27 Oct 2010 16:23:12 GMTdoofledorferhttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]RobertYoung (10/27/2010)[/b][hr][quote][b]alen teplitsky (10/27/2010)[/b][hr]Now, whether any organization would refactor its databases is another question; one which always amuses me, given that coders, virtually en masse, preach "refactor your code". I guess it's a matter of whose ox is getting gored.[/quote]Hmmm I thought I'd put in a comment here because the thinking on this blog is going to the same place that it always tends to go when I present RAP to people.If an organization has to be dragged kicking and screaming to refactor its databases, or if developers are grudgingly adopting database object naming conventions in order to get the code-generating features of RAP or something like RAP, then they're going to fail because they are missng the point.The point is not to have a code generator. Nor is auditing the point. Nor are the twenty-or-so other side benefits RAP.The point is to impose a discipline which makes all sorts of things possible that weren't possible before. The code generator is just a pleasant side-effect of the discipline - it's one of the new possibilities. RAP's simple ORM is also another side-effect. There are other side-effects that I haven't even explored yet - things that can and will be implemented easily and simply because some discipline was imposed on the database design.Some of the posts here complain about RAP's naming convention, suggesting that developers should have essentially no systematic regularity to their object names. Well that is fine but unfortunately other people might not be able to figure out your database objects by their names, and you might as well toss out the notion of automatic code generation because it simply isn't going to work. The naming convention is not some unnecessary blight imposed by a control freak (me). Rather it's a discipline that makes tons of things possible. If people can't stand the discipline, then they should feel free to remain mired at our current level of productivity forever.If an organization does not get the idea that the discipline is the starting point and that the discipline makes possible all the benefits that flow from it, then we are back at square one. Once again I use the automobile analogy. Most of the people working for Ford in 1913 didn't understand the point of all this ridiculous standardization because they were forever thinking at the component level, not the system level. People thought Ford was a fool for imposing all sorts of requirements that had never been imposed before. Why use the same screw every time in the same hole? Why not just use whatever is on hand? Why bother specify the design of a car down to the umpteenth level when hand-improvisation has been working just fine for decades? Why make the car only in black? And on and on.All these arguments are just lovely until the day you face some serious competition.Wed, 27 Oct 2010 14:30:58 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic1011241-314-1.aspx[quote][b]alen teplitsky (10/27/2010)[/b][hr]i don't have as much gray whiskers as others, but in my experience the problem isn't reinventing the wheel but adding to it over the years. so and so customer wants some feature so you add a few tables or columns. the business grows into another product area means more tables added. etc. another app comes along that needs a new database but it also needs data from the core databases that have been around for years so again you don't need to reinvent the wheel. just add a spoke here and there from time to time.the problem is not the SQL most times it's the application code. over the years the core classes will grow to the point where a lot of functionality is concentrated in a few core C# or Java classes and you have to test against a lot of apps every time you make code changes[/quote]The point of such endeavors, and David's is by no means the first (the earliest I'm aware of were COBOL/VSAM generators in the early 70's), is to replace data integrity in code with data integrity in data. After all, your code, ultimately, just implements a bunch of data compares; code logic boils down to data logic in a pretty pink dress. With all logic in data, extension with a code generator is a matter of adding tables and columns, perhaps with triggers/functions/procs. Writing a generator which extracts logic in database code is non-trivial compared to one which just implements DRI on the client. To paraphrase Shakespeare, "first thing we do, is kill all the client coders".Now, whether any organization would refactor its databases is another question; one which always amuses me, given that coders, virtually en masse, preach "refactor your code". I guess it's a matter of whose ox is getting gored.Wed, 27 Oct 2010 13:23:00 GMTRobertYoung