InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comTue, 18 Jun 2013 18:09:43 GMT20http://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]David Ziffer (10/6/2010)[/b][hr][quote][b]timothyawiseman (10/6/2010)[/b][hr]I think it makes sense to decide, if not table by table, then certainly database by database whether you want to use artificial keys. I find the idea of standardized audit fields even worse since they do not make sense for all tables, and unused fields tend to create confusion and waste.As to the comparison with the auto industry, I find it flawed. There the goal is precisely to mass produce large numbers of nearly identical products with interchangeable parts. It makes tremendous sense to standarize virtually everything in that and keep producing them. But no two software projects are absolutely identical (if they were, you would just copy the first one and be done with it). Another thing to point out is that most assembly line workers are not the same as craftsmen. They just repeat the same thing over and over without trying to optimize for absolute performance. Software creation is much closer to that situation, then to assembly line workers repeating the same motions over and over.[/quote]Many good points here Timothy and let me respond to them. First with regards to artificial keys ... the whole point with RAP is to standardize the code generation and the ORM. I think it should be self-evident that one fantastic way to standardize and simplify an app is to have all the keys look exactly the same. It would be way beyond the scope of this article and this blog for me to discuss all the benefits of using artificial keys, but let me focus on just one: you simply cannot audit a table that doesn't have one. Without an artificial key, there is no field in the table that guarantees continuity from one version of a row to the next (since business keys can always change). So artificial keys are critical to auditing.Most people have never seen a 100% auditing application and so they can't imagine why you'd want to put status fields on every table. Well ... RAP produces 100% auditing apps. What this means is that you can actually log into your application "as of" a given date, and the app will open up with all of your data displayed as of that date. Screens, web pages, reports, everything. Even a web service, if that's what you're running. And that's just one advantage of having status fields in all tables. It's in the demo .. give it a try.With regards to the auto analogy. Yes the analogy is flawed, because we are one level of abstraction higher here. With an auto assembly line the objective is to make a zillion of exactly the same thing. With RAP the objective is to make a zillion things whose underlying "plumbing" is built exactly the same way. A much better analogy would be the analogy to compilers, which use the same parameter-passing and code-generation techniques everywhere, but tailor them to whatever code you're writing.But the automobile analogy is sexier.[/quote]Wow... so much wisdom in this...Wed, 28 Dec 2011 07:30:19 GMTDiegoPeñahttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxGreat that somebody write about this stuff. We are practiceing this stuff even in a more advanced way since 2004 :-D. And it is very very useful and fast aproach.Wed, 27 Oct 2010 01:22:21 GMTMilos Cigojhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxHi Ken,I was perhaps trying to be provocative to make a serious point :)Re:- "In my opinion, *less* code is almost always a good thing - assuming it reduces complexity, maintenance costs, defects. Regardless of which tier the code lives on." - Sure, who would disagree?The thrust of my observation, is that by definition imperative programming languages (such as C#) almost force programmers (or rather lure?) them into micro-managing data, and decision making in software.Having components that automatically write the SQL code is fine, provided that is really what is useful.I tend to find that so many problems that are a pain to write in C#, are so much easier solved in SQL, provided you follow the 'natural' 'flow' and 'grain' of information.The 'right' solution to a problem can very often be missed as organisations/managers/developers can say "We don't need to pay attention to what goes on in SQL, as we have this wonderful code-writing tool that writes our code for us".My fear of taking this approach is that you end up with (bloated and) busy middle-tiers whiring and grinding round and round, and simply killing the associated SQL box with a barage of requests. This drives up hardware and licensing costs ("we won't write the code properly, just throw more application servers at the problem. SQL box dying? Get another bigger box. Data center suddenly not got enough power? Move to another one." etc.)Of course, sometimes line-item approaches are best / absolutely required. It all depends on the nature of the system.Wed, 20 Oct 2010 10:56:38 GMTCraig@Workhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxHi,And if you need more tsql programmers to compensate for less c# programmers, where is the gain? In my opinion, *less* code is almost always a good thing - assuming it reduces complexity, maintenance costs, defects. Regardless of which tier the code lives on.kenWed, 20 Oct 2010 09:53:46 GMTkenambrosehttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxThe trouble is though that the CRUD procedures auto-generated are effectively line-item procedures? i.e. the processing is done RBAR.Creating procedures to do this, means effectively grinding through programming data into the database almost column-by-column, line by line.I found the switch to TVPs very effective in stripping out so much procedural rubbish that imperative programming favours, and this encourages a much more intuitive style of programming in both C# components and in SQL itself.Sure you need to have a SQL developer on hand to do this. But if you can have fewer C# coders as a result, what is the loss? :)Wed, 20 Oct 2010 03:38:18 GMTCraig@Workhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]moisixhaf (10/10/2010)[/b][hr][quote][b]simon-623950 (10/6/2010)[/b][hr] ... the SQL developer mus be really the dude with a lot of brain in there and the others must respect the datatypes and the constraints he puts otherwise the final result will be like using bags of text instead of consistent data to store your information ... But this is just an opinion :cool:[/quote]It may be just an opinion, but it's a great one!Sat, 16 Oct 2010 06:54:26 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]chrisl 5993 (10/16/2010)[/b][hr]Great article, and fascinating comments. I have downloaded the software, run it, and run into a problem. Where can I get help on the problem?[/quote]Send an email to DaveZiffer@ProjectPro.comSat, 16 Oct 2010 06:52:06 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxGreat article, and fascinating comments. I have downloaded the software, run it, and run into a problem. Where can I get help on the problem?Sat, 16 Oct 2010 00:15:56 GMTChrisLanehttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]simon-623950 (10/6/2010)[/b][hr]I'm glad I don't work in an environment where I rely on someone else designing the database then someone else programming the datalayer then someone else designing the frontend. Surely in any project you would put heads together and come up with a plan before just going ahead and bodging together a database then expecting everyone else to work with it.[/quote]Actually I am working in an environment where I created a database that fits the "frame" and ideas in this article (primary keys data audit fields etc) and the app developer that is coding in vb is totally out of the purpose of the project ... I would say that at the end the data will be stored in a database and this is the root of many projects involving SQL in any of its flavors ... the SQL developer mus be really the dude with a lot of brain in there and the others must respect the datatypes and the constraints he puts otherwise the final result will be like using bags of text instead of consistent data to store your information ... But this is just an opinion :cool:Sun, 10 Oct 2010 03:34:38 GMTmoisixhafhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxWhile I too had trouble with the analogy and remain a bit sceptical, I think the idea has merit and is worth exploring. I hope to keep an open mind.I appreciate the author sharing this idea with us, sharing his code/app, and also taking the time to write such thoughtful replies to the comments. I look forward to future articles. Thanks.Fri, 08 Oct 2010 16:01:30 GMTJJ Bhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]Ed Salva (10/8/2010)[/b][hr]I'm enjoying reading the comments, but I'm curious, what happens when someone comes up with a better engine (or as in our case better software)?Do we buy into it, or ride the current wave until it is exhausted? perhaps because it's easier or cheaper? Then at the end of the ride were do you go?Standards are a good thing. It helps with continuity and somewhat simplifies things. if "continuous quality improvement" is part of the process then the best you can have is the "standard du jour"[/quote]Ed: First of all, RAP doesn't leave you with something that you can't maintain without the ongoing use of RAP. At the end of the day you still have a chunk of .NET and SQL code that you can continue to maintain by hand if you wish. It's just that it's probably a much more consistent and better structured piece of code than you possibly could have had the time or the budget to write yourself. So you don't incur any substantial risk by using RAP in terms of being left high and dry with something unusable afterwards.Secondly there is no wave to ride. There is no crowd to follow. So this is an adventure, and instead of deciding whether to go with the crowd you'll have to instead decide whether this tool and this paradigm would make your life a whole lot easier. I'm not expecting many followers. I just want a few that will allow both me and my company to demolish my competition in a real-world demonstration of what is possible when you automate things rather than redo them by hand constantly.The "standard du jour" argument could be used to exempt one's self from using any technology. How about C#? Remember C# is the replacement for non-compatible VB.NET in many shops. And VB.NET was the replacement for non-compatible VB6. Good heavens, why use compilers at all? If we really want to avoid paradigms and tools, we could even dispense with operating systems and go back to coding machine language. But oops - your machine language constitutes a possibly misguided investment in a particular processor architecture! Where does one turn? It seems that no matter where you look, you are making an investment in one technology or another.Even if your vendor is Microsoft, there's no assurance that the tool(s) you're using today won't be obsolete tomorrow. The choice with RAP is to have a tool that generates most of your app code automatically, complete with features you could never afford to implement by hand, or alternatively to go without and reinvent the wheel - probably meagerly due to budget & time constraints - with every new app you have to write. The choice, of course, is yours.Fri, 08 Oct 2010 15:47:43 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxI'm enjoying reading the comments, but I'm curious, what happens when someone comes up with a better engine (or as in our case better software)?Do we buy into it, or ride the current wave until it is exhausted? perhaps because it's easier or cheaper? Then at the end of the ride were do you go?Standards are a good thing. It helps with continuity and somewhat simplifies things. if "continuous quality improvement" is part of the process then the best you can have is the "standard du jour"Fri, 08 Oct 2010 11:27:52 GMTEd Salvahttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote]even if in most places (as you assert) they are doing it consistently and systematically[/quote]I didn't assert that; I only took issue with your assertion to the contrary.Like you, I have seen and workd with many designs that have annoyed me to death. I knew, in contrast to your assertion, that the cause was not that someone had obssesed over the design. Quite the opposite: the designers did not know what the needed to know to ask the right questions to do it right, or to turn the right answers into a design that best supported that. Last comment from me on this topic, but I found the discussion very interesting.Thu, 07 Oct 2010 13:56:52 GMTRonKylehttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]RonKyle (10/7/2010)[/b][hr][quote]RAP is in the same spirit. The objective is to properly and systematically do what most programmers currently do both imporperly and inconsistently. They do these things poorly because they're being paid to create functionality, not diddle with plumbing, and so the plumbing always gets short shrift and is done as an afterthought.[/quote]Most of what you just said in your post sounds interesting, but the paragraph above just does not reflect the complete reality. Some of us have put a lot of time into our programming to ensure the plumbing is done "correctly", in the sense of efficiency. And when sometimes time doesn't permit, take the time to refactor the code at a later date. I think you would find that your ideas might have more traction if you avoided the negative statements.[/quote]Ron: I'm sorry if I seem overly negative to you. It's just that I can't see the point of people doing all this mundane stuff by hand, even if in most places (as you assert) they are doing it consistently and systematically. Maybe we come from radically different environments. If I were not profoundly annoyed by the stuff I see in most designs, I wouldn't have spent much of my free time over the last five years trying to automate the generation of appication infrastructure.Thu, 07 Oct 2010 13:50:16 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]gbaytler (10/7/2010)[/b][hr]Column in the application is defined as 'DATE', which is not available as a datatype in SQL Server 2005. It is introduced in SQL Server 2008.The article text should be changed to indicate that SQL Server 2008 is required.[/quote]Here is a specific fix for SQL Server 2005, which is not really supported any more:First of all start the whole procedure over with a blank database. But before you start populating the database, edit the file “DataTypes.sql”. In there you will find these two lines: exec sp_addtype 'DTDate', 'date', 'null' exec sp_addtype 'DRDate', 'date', 'not null'Change the ‘date’ types to ‘datetime’. Then start populating the database from scratch according to the instructions. This should then work with SQL Server 2005.Thu, 07 Oct 2010 13:16:57 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote]RAP is in the same spirit. The objective is to properly and systematically do what most programmers currently do both imporperly and inconsistently. They do these things poorly because they're being paid to create functionality, not diddle with plumbing, and so the plumbing always gets short shrift and is done as an afterthought.[/quote]Most of what you just said in your post sounds interesting, but the paragraph above just does not reflect the complete reality. Some of us have put a lot of time into our programming to ensure the plumbing is done "correctly", in the sense of efficiency. And when sometimes time doesn't permit, take the time to refactor the code at a later date. I think you would find that your ideas might have more traction if you avoided the negative statements.Thu, 07 Oct 2010 12:57:46 GMTRonKylehttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]David Ziffer (10/7/2010)[/b][hr][quote][b]Ahmed Saad (10/7/2010)[/b][hr]I am also developing an application with similar goal as that of RAP but with a different approach. It is UI driven, which means all the back-end stuff will be generated by the screens designed by a domain expert. [b]Zoho.com[/b] has a similar application called [b]Creator[/b] but it is much difficult to use as compared to the design I am working on.[/quote]Ahmed: I am not one to generally discourage people from trying exciting new stuff, but you might want to reconsider the top-down approach before you invest a whole lot more time in it. I have had several people in the past point out the fact that there are already UI-based code generators that generate the database, but I have never taken the bait.As a consultant I have seen many schemas in many places. If I had to identify the one most crippling problem I see in all of database-land, it is the tendency of schema designers to create schemas where the tables look just like screens of the UI. Such schemas tend to be highly denormalized and further they don't generally model the real-world structure of the problem (since the UI doesn't generally do that), making their databases highly resistant to modification, including modifications needed to make them support new user interfaces.This is especially important in the current environment where applications increasingly must support multiple UIs, including (possibly) native client, web, mobile, and web service. A mobile UI will generally be much more fragmented than a native client or web interface. Would a top-down solution that supports all of these interfaces actually generate the same database from all of them? I personally cannot imagine how a translator could create a good schema, which requires deep real-world understanding of the problem and profoundly good modeling skillls, from something as superficial as the current UI spec. Then of course there's the problem of supporting a version of your product that generates code from every UI that a programmer possibly could possibly need to support. Even if you could afford to do this, how would you reconcile them?Here's an example of the problem with UI-driven design. In the consulting business UIs tend to be client-driven because the UI is generally the only thing the client understands. Suppose you are designing a CRM system for a client who tells you that he wants a UI in which the screen (or page or whatever) displays one phone number for each person. Now you know perfectly well that next year this client is going to realize his mistake and come back and require you to allow for multiple phone numbers, but for the moment there is no dissuading him. With a bottom-up generator like RAP you'd just design the database properly anyway (without the client even knowing) and give him the UI he wants. Next year the only thing you'll have to change is the UI. But with a top-down generator you'll be stuck with a schema that supports only one phone number per person.This is why I chose the bottom-up approach. RAP will not and cannot make the schema designer's job go away, because of all the components of app design the schema requires the deepest insight into the true nature of the problem. A serious app designer models the real world, not the current UI's vision of it, and RAP lets him do that.In my opinion there is no escape from good schema design. RAP obsolves the schema designer from making the generally arbitrary decisions regarding keys, status fields, and auditing that I see being made poorly every day. It's very much analogous to compilers (replacing assembly language) absolving programmers from the need to design a parameter-passing convention for every function they write. But at the end of the day, if your schema isn't properly normalized and well structured, you're doomed no matter what tools you're using.[/quote]David. Single big reason why I took UI-driven approach is that I think there is no major difference in any two relational databases, no matter how different those are domain wise; one might be a mission critical NASA database while the other just an inventory database of a store. Biggest fact of all relational databases is that they are set of master-detail tables, so what if we can find a UI design as well acceptable to everyone? I feel it is quite possible.Your point about flexibility to accommodate changes is good. I think it is also do-able. Though I can't think of another example (because my children are crying in top volume :)) but the one-telephone-per-person problem will not be a big issue in my design. From a schema designer's point of view, they will typically need a child table to store multiple phone numbers. My application will add this table according to UI change and then user will have to migrate existing phone numbers from parent table to child table, which can be done manually or by some DTS like activity.I will be glad to hear more from you on this subject and also to share more information about my application.Thu, 07 Oct 2010 12:56:15 GMTAhmed Saadhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]eric.cardinal (10/7/2010)[/b][hr]At the end of the article it kind of sums it up for me where you are going with this...Henry Ford's craftsman didn't like the assembly line approach either. This is a very telling comment. To me this is more of a philisophical discussion than one of simple code efficiency, creating a code monkey is not what I want as a supervisor. I need people who can solve complex problems, creatively. I know you are only describing creation of "plumbing" here but the title of your article proclaims the production of limited interaction cookie cutter applications, a consistent approach to anything is admirable. But, the loss of the craftsmen creates a gap in ingenuity and innovation...I would hate to see the same thing happen to this industry as has happened to many others. Noble idea but I have a dissenting view on making things too cookie cutter. A few things you forgot to mention about the Japanese auto makers and their efficiency culture. They work 14-16 hour days...6 days a week, they have a negative population growth, and retirement is mainly a dream. I like people where I work but I don't want to spend my life with them...there is a balance.Cheers.[/quote]My view as a technologist is that our job is to move things forward. We do this by relieving humans of relatively mindless repetetive work that shouldn't need to be redone, probably poorly, by every person who's trying to achieve something.In the 1800s every house had a weaving loom and of necessity the woman of the house spent many of her daily hours making clothes. Today factories do the same job more efficiently and consistently and women are free to do other things, including make clothes for fun if that is their inclination.In the 1960s assembly language programmers spent significant amounts of their time reinventing the plumbing of parameter passing, looping, and so forth. Today compilers do all these things consistently and accurately, vastly reducing the amount of time that we all need to create real functionality.RAP is in the same spirit. The objective is to properly and systematically do what most programmers currently do both imporperly and inconsistently. They do these things poorly because they're being paid to create functionality, not diddle with plumbing, and so the plumbing always gets short shrift and is done as an afterthought.RAP is to application design what compilers are to program writing ... it's a fundamentally different environment in which programmers are relieved of mundane tasks they shouldn't need to do and are rewarded with automatic functionality that they could never afford to implement if they had to do the mundane tasks by hand.RAP will not turn programmers into assembly line workers. With RAP, as with compilers that generate your machine code, the assembly-line work is done by the computer, leaving you free to think about grander things than how to implement auditing all over again (RAP gives you auditing, among many other things, for frree).So please, let's move forward. Automation ultimately leads to a higher standard of living, even if it forces some of us to re-educate ourselves. At the end of the day I would hope that creating a higher standard of living is what we're all about.Thu, 07 Oct 2010 09:18:24 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxAt the end of the article it kind of sums it up for me where you are going with this...Henry Ford's craftsman didn't like the assembly line approach either. This is a very telling comment. To me this is more of a philisophical discussion than one of simple code efficiency, creating a code monkey is not what I want as a supervisor. I need people who can solve complex problems, creatively. I know you are only describing creation of "plumbing" here but the title of your article proclaims the production of limited interaction cookie cutter applications, a consistent approach to anything is admirable. But, the loss of the craftsmen creates a gap in ingenuity and innovation...I would hate to see the same thing happen to this industry as has happened to many others. Noble idea but I have a dissenting view on making things too cookie cutter. A few things you forgot to mention about the Japanese auto makers and their efficiency culture. They work 14-16 hour days...6 days a week, they have a negative population growth, and retirement is mainly a dream. I like people where I work but I don't want to spend my life with them...there is a balance.Cheers.Thu, 07 Oct 2010 08:20:00 GMTeric.cardinalhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]gbaytler (10/7/2010)[/b][hr]Column in the application is defined as 'DATE', which is not available as a datatype in SQL Server 2005. It is introduced in SQL Server 2008.The article text should be changed to indicate that SQL Server 2008 is required.[/quote]Thanks for pointing this out. For the moment you can change it to "datetime" and it will work.Thu, 07 Oct 2010 07:57:20 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxColumn in the application is defined as 'DATE', which is not available as a datatype in SQL Server 2005. It is introduced in SQL Server 2008.The article text should be changed to indicate that SQL Server 2008 is required.Thu, 07 Oct 2010 07:52:01 GMTgbaytlerhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]Ahmed Saad (10/7/2010)[/b][hr]I am also developing an application with similar goal as that of RAP but with a different approach. It is UI driven, which means all the back-end stuff will be generated by the screens designed by a domain expert. [b]Zoho.com[/b] has a similar application called [b]Creator[/b] but it is much difficult to use as compared to the design I am working on.[/quote]Ahmed: I am not one to generally discourage people from trying exciting new stuff, but you might want to reconsider the top-down approach before you invest a whole lot more time in it. I have had several people in the past point out the fact that there are already UI-based code generators that generate the database, but I have never taken the bait.As a consultant I have seen many schemas in many places. If I had to identify the one most crippling problem I see in all of database-land, it is the tendency of schema designers to create schemas where the tables look just like screens of the UI. Such schemas tend to be highly denormalized and further they don't generally model the real-world structure of the problem (since the UI doesn't generally do that), making their databases highly resistant to modification, including modifications needed to make them support new user interfaces.This is especially important in the current environment where applications increasingly must support multiple UIs, including (possibly) native client, web, mobile, and web service. A mobile UI will generally be much more fragmented than a native client or web interface. Would a top-down solution that supports all of these interfaces actually generate the same database from all of them? I personally cannot imagine how a translator could create a good schema, which requires deep real-world understanding of the problem and profoundly good modeling skillls, from something as superficial as the current UI spec. Then of course there's the problem of supporting a version of your product that generates code from every UI that a programmer possibly could possibly need to support. Even if you could afford to do this, how would you reconcile them?Here's an example of the problem with UI-driven design. In the consulting business UIs tend to be client-driven because the UI is generally the only thing the client understands. Suppose you are designing a CRM system for a client who tells you that he wants a UI in which the screen (or page or whatever) displays one phone number for each person. Now you know perfectly well that next year this client is going to realize his mistake and come back and require you to allow for multiple phone numbers, but for the moment there is no dissuading him. With a bottom-up generator like RAP you'd just design the database properly anyway (without the client even knowing) and give him the UI he wants. Next year the only thing you'll have to change is the UI. But with a top-down generator you'll be stuck with a schema that supports only one phone number per person.This is why I chose the bottom-up approach. RAP will not and cannot make the schema designer's job go away, because of all the components of app design the schema requires the deepest insight into the true nature of the problem. A serious app designer models the real world, not the current UI's vision of it, and RAP lets him do that.In my opinion there is no escape from good schema design. RAP obsolves the schema designer from making the generally arbitrary decisions regarding keys, status fields, and auditing that I see being made poorly every day. It's very much analogous to compilers (replacing assembly language) absolving programmers from the need to design a parameter-passing convention for every function they write. But at the end of the day, if your schema isn't properly normalized and well structured, you're doomed no matter what tools you're using.Thu, 07 Oct 2010 07:06:07 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]scoia (10/6/2010)[/b][hr]<<Since 2006 Honda has made all the engines in all 33 cars of every Indy race, so no matter who wins, Honda wins.>>Just curious, but for the sake of a logic twist in this conversation. . .if the above statement is true, isn't it equally true that "no matter who loses, Honda loses"? :-)[/quote]Sorry, can't help myself.No, no matter who loses Honda wins would be correct. You're comparing apples and oranges. For the race loser Honda is still a winner since the engine made by Honda :-)Thu, 07 Oct 2010 05:13:17 GMTKristian Askhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxI am also developing an application with similar goal as that of RAP but with a different approach. It is UI driven, which means all the back-end stuff will be generated by the screens designed by a domain expert. [b]Zoho.com[/b] has a similar application called [b]Creator[/b] but it is much difficult to use as compared to the design I am working on.Thu, 07 Oct 2010 02:07:18 GMTAhmed Saadhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]timothyawiseman (10/6/2010)[/b][hr]I think it makes sense to decide, if not table by table, then certainly database by database whether you want to use artificial keys. I find the idea of standardized audit fields even worse since they do not make sense for all tables, and unused fields tend to create confusion and waste.As to the comparison with the auto industry, I find it flawed. There the goal is precisely to mass produce large numbers of nearly identical products with interchangeable parts. It makes tremendous sense to standarize virtually everything in that and keep producing them. But no two software projects are absolutely identical (if they were, you would just copy the first one and be done with it). Another thing to point out is that most assembly line workers are not the same as craftsmen. They just repeat the same thing over and over without trying to optimize for absolute performance. Software creation is much closer to that situation, then to assembly line workers repeating the same motions over and over.[/quote]Many good points here Timothy and let me respond to them. First with regards to artificial keys ... the whole point with RAP is to standardize the code generation and the ORM. I think it should be self-evident that one fantastic way to standardize and simplify an app is to have all the keys look exactly the same. It would be way beyond the scope of this article and this blog for me to discuss all the benefits of using artificial keys, but let me focus on just one: you simply cannot audit a table that doesn't have one. Without an artificial key, there is no field in the table that guarantees continuity from one version of a row to the next (since business keys can always change). So artificial keys are critical to auditing.Most people have never seen a 100% auditing application and so they can't imagine why you'd want to put status fields on every table. Well ... RAP produces 100% auditing apps. What this means is that you can actually log into your application "as of" a given date, and the app will open up with all of your data displayed as of that date. Screens, web pages, reports, everything. Even a web service, if that's what you're running. And that's just one advantage of having status fields in all tables. It's in the demo .. give it a try.With regards to the auto analogy. Yes the analogy is flawed, because we are one level of abstraction higher here. With an auto assembly line the objective is to make a zillion of exactly the same thing. With RAP the objective is to make a zillion things whose underlying "plumbing" is built exactly the same way. A much better analogy would be the analogy to compilers, which use the same parameter-passing and code-generation techniques everywhere, but tailor them to whatever code you're writing.But the automobile analogy is sexier.Wed, 06 Oct 2010 19:50:38 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]Roger L Reid (10/6/2010)[/b][hr]Another silver bullet for "what's wrong with software development".The rhetoric is familiar:1. Assert such a problem exists - "every knows it", so no analysis needed2. Make a flawed analogy with some other production process, without exploring its relevance.3. Show the [Concept|Product], in its Blinding Simplicity, that once and for all will make software development Easy and Cheap.There are no silver bullets. [/quote]Roger: I think the question here really is whether I have got something worth trying that really makes writing applications more efficient. I agree that there have been many "solutions" that really weren't very good because they can't be generalized, they cause more problems than they solve, etc. Maybe mine is one of them.Then again there are true leaps in technology. Like when we went from machine code to assembly language, for example. Or from assembly language to compiled code. Or from procedural design to object-oriented design. Or from flat-files to relational databases, for that matter.Silver bullets all.Wed, 06 Oct 2010 19:27:57 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]C. Grant Anderson (10/6/2010)[/b][hr]A lot of talk about relative points and yes it does really look like a promotional ad. After skimming the website and related white paper the big questions in my mind are:1. Has anyone tried using this and can give us an objective evaluation about how useful this really is in the real world? The software world is full of a lot of claims and oft times they sound like a good idea but do they really deliver the automation of software development? How is it with this product?2. There's a supposition here that the database design is complete and perfectly in 4NF. That's a very big supposition. In app development no database is ever fully complete. So what happens in this product when the underlyng database must change? How does this product/approach handle the necessary changes? Easily? Poorly? This is real world effect that is critical.3. There's not enough real world info in the article or the website's white paper to get a good overview of the approach nor is there is full instance of an app created and presented. So, is this just a middle tier automation approach that ignores the database as well as the GUI? It looks like a lot of work went into this, and a lot of work is required to set it up and get it running (having to create some definition files...say, can't it just read it directly from the DB?), but just how useful and practical is this in the real world situations? (This wraps back to my point #1).Can someone who has tested this post their results and comments here?Thanks. - Grant[/quote]Grant: Sorry about the appearance of an ad. You might read my previous post on this subject. It's hard to distribute software to people without it looking like some sort of promotion.The only people who have used RAP in actual application development are myself and people working for and with my company. I cannot show you real-world apps we developed using it because they are the internal property of my company's clients.I am trying very hard to broaden the usage base of RAP. Unfortunately in order to make that happen I first have to make people aware of RAP before such a base exists. So it's a Catch-22 if I'm to be required to demonstrate an installed base before popularizing the concept.With regards to the fact that schemas change ... yes they do and RAP handles this very well. In fact it handles change much better than hand-written apps do. Generally speaking when you change your schema, you must do it by altering existing tables (since you can't just recreate them due to the existing data, foreign key relations, etc.). The RAP code generators look right into the database and generate entirely new CRUD code and data-layer code from the schema that you actually have in there. So you can do all the ALTERs you want, then rerun the RAP generator and both your database CRUD and your data layer code will be automatically updated for you. And because of RAP's strict enforcement of multi-tier structure, your app will likely survive very nicely due to the absence of specialized hand-written hard-code that depended on the old schema.And finally thank you for your assessment about the amount of work that went into this. Right now it's five years of evenings and weekends and counting.Wed, 06 Oct 2010 19:19:35 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]bienvenunet (10/6/2010)[/b][hr]Question: Can RAP and the concepts that the series will discuss be used to develop Web Parts and features for SharePoint?[/quote]I have no experience with coding SharePoint and so unfortunately cannot answer this question directly. However I can give you some guidelines that might allow YOU to answer the question.RAP requires that you build the whole database using RAP's design methods. Your app's database can of course interface to other databases and you can store foreign keys to other databases' tables inside of RAP tables, but RAP's ability to interact with other data ends at the boundaries of its own tables.If SharePoint is similar to, say, Microsoft's Enterprise Library logging and authentication features, where the Microsoft-supplied part of your app is stored in its own separate SQL Server database (and you connect the various databases via your app) then a RAP-based application can work with SharePoint. However if you are required to mix your schema in with SharePoint tables in the same database, then the usability of RAP is doubtful.Wed, 06 Oct 2010 19:02:52 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]andycao (10/6/2010)[/b][hr]That's how I saw it. Gosh, an ad disguised as a SQL Server Central article. OK, moving on...[/quote]I thought I'd explain my position here (as the author). I am a software consultant and the company web site on which Rapid Application Prototype is posted is my company's web site. There is of course the possibility that publishing this article could lead my company to do some business that it would not otherwise have done. But that's about it for financial benefit. If RAP were a product for sale, it would have a price tag.This article would be pretty pointless if I did not distribute sofware that actually does what the article talks about. Without the software, it'd be just another pleasant-sounding vague idea.The software is distributed free of charge. I long ago gave up on the idea of selling both the concept and the software after trying it out on folks and realizing how few of them had any idea what I am talking about. My response from most people is a polite "that's nice" and then they move on.My personal benefit in publishing this article is that I am hoping to find the handful of people who have an interest in process improvement and who believe that the way we do things now is incredibly sub-optimal. I don't know what would come of my association with such people, but nonetheless I would dearly love to meet them. I suspect there are very few of them, and without an article series like this one my odds of finding them (or them finding me) would be almost nil.Wed, 06 Oct 2010 18:50:46 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx"I think the article would have been much more effective had it just focused on the product rather than negatively portray people who are trying to do their job diligently."Actually I think it's very important to get the schema right. The behavior I was criticizing is where database designers and DBAs spend all their time thinking and making significant variations at the single-table level and little or no time thinking of the consequences of the inconsistencies they are probably introducing into both the database and the application.Wed, 06 Oct 2010 18:31:23 GMTDavid Zifferhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]kenambrose (10/6/2010)[/b][hr]Having different specifications for a finished deliverable does not mean the methods one uses to implement the deliverable have to be different.I worked for years in custom manufacturing industry. Almost every job, even for the same client over time, had custom specifications. But we used the same management, production, and control methods to produce the finished product.I think you may be confusing methods with specs.[/quote]I could see how that would be a conclusion, but I don't believe I am. It's also possible that I see DB'ing as more complex because I don't tend to work on the cookie cutter jobs. The custom specs, especially from a DB side, tend to interfere more with the basic methodology.Where in one case a natural key exists and makes sense, in another while existing, it isn't feasible because you need a better methodology to speed up query logic. While the generic CRUD might be acceptable here, in another case you may need to build in logic controls because you're using a multi-table master so you can't enforce via Foreign Key.The Custom specs drive a lot more of the base development of a DB engine than a car engine, especially when it comes to tuning and performance.Wed, 06 Oct 2010 16:09:54 GMTEvil Kraig Fhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxHaving different specifications for a finished deliverable does not mean the methods one uses to implement the deliverable have to be different.I worked for years in custom manufacturing industry. Almost every job, even for the same client over time, had custom specifications. But we used the same management, production, and control methods to produce the finished product.I think you may be confusing methods with specs.kenWed, 06 Oct 2010 15:51:34 GMTkenambrosehttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxTo hose down the inbound flame war:Regardless of how the R&D department at Honda works, the point is that the engine is a finished product, then reproduced.The equivalent of a vendor's final development, and is shipping a software product to clients. Every honda engine is not built from the same set of base specs to mimic the now beautiful Indy500 engine, but it does have pistons, spark plugs, etc. It's the equivalent of our tables, procs, and the like.If we perfect a DB, sure, we'll distribute it to do that job. Reaching that point is not necessarily the product of completely standardizing the entire build process.Wed, 06 Oct 2010 15:32:35 GMTEvil Kraig Fhttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxUmm, you are not worth the time, sorry.Wed, 06 Oct 2010 15:27:47 GMTkenambrosehttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]kenambrose (10/6/2010)[/b][hr]Umm, do some research and you can answer your own question.[/quote]You are the one saying I was "Very incorrect". If you can't backup your statement, I guess there is nothing to talk about.Wed, 06 Oct 2010 14:12:12 GMTMichael Valentine Joneshttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxUmm, do some research and you can answer your own question.Wed, 06 Oct 2010 13:48:18 GMTkenambrosehttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx[quote][b]kenambrose (10/6/2010)[/b][hr]Very incorrect, and I can say for sure you have done no research or investigation into engineering development methods at Japanese automakers.[/quote]So, you are saying Honda engineers would let adherence to some half-formed methodology get in the way of getting the job done right?Wed, 06 Oct 2010 13:43:15 GMTMichael Valentine Joneshttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxVery incorrect, and I can say for sure you have done no research or investigation into engineering development methods at Japanese automakers.Wed, 06 Oct 2010 13:29:09 GMTkenambrosehttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspxI think the analogy is completely flawed.If you want a true analogy, it would be between the process used to design and develop the engines and the software development process. I think you would find that the engine development process is probably just as messy as the software development process, and that the Honda engineers would not let adherence to some half-formed methodology get in the way of getting the job done right.Wed, 06 Oct 2010 13:18:47 GMTMichael Valentine Joneshttp://www.sqlservercentral.com/Forums/Topic998923-314-1.aspx<<Since 2006 Honda has made all the engines in all 33 cars of every Indy race, so no matter who wins, Honda wins.>>Just curious, but for the sake of a logic twist in this conversation. . .if the above statement is true, isn't it equally true that "no matter who loses, Honda loses"? :-)Wed, 06 Oct 2010 12:32:37 GMTscoia