Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12345»»»

Writing Nearly Codeless Apps: Part 1 Expand / Collapse
Author
Message
Posted Tuesday, October 5, 2010 9:27 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 6, 2013 2:24 PM
Points: 69, Visits: 182
Comments posted to this topic are about the item Writing Nearly Codeless Apps: Part 1
Post #998923
Posted Tuesday, October 5, 2010 10:17 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Friday, September 12, 2014 6:02 PM
Points: 75, Visits: 488
I agree wholeheartedly that there are a lot of arbitrary decisions typically made in custom application development on many levels that could - and should - be standardized. The waste, inefficiency, and poor quality that results from such arbitrariness is huge I am sure. The analogy to the Indy 500 engines is beautiful.

Having said that, it isn't exactly a new idea. In fact there is not a single shop I have worked for in my career where the concept was not part of the discussion of the practice of software development (maybe I've just been lucky but I don't think so).

I would however make some different choices in the "tiering" than what was presented in the article. For example, I often put some of the "rules" of an app, if not most, in the DB server. That way no rogue application or updates can bypass them. In fact my motto is "The usefulness of a database to it's owners over the course of it's lifetime is directly proportional to the proportion of data constraints that are placed in the DB server vs. the application code"

I haven't worked through the example code yet but I expect it would not be a problem to put the important rules in the DB tier?

ken





Post #998928
Posted Tuesday, October 5, 2010 11:56 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, November 26, 2013 4:48 PM
Points: 2, Visits: 13
This is exactly the kind of template-driven, data-dictionary-based development Clarion has provided to DOS and Win32 developers for over 20 years. You can learn more about Clarion at http://clarionmag.com.

Finding a .net solution that does this would be killer. Clarion's .net solution remains unreleased.

Mark
Post #998978
Posted Wednesday, October 6, 2010 12:03 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Saturday, June 7, 2014 7:51 PM
Points: 42, Visits: 351
Great idea! Anyone that has taken an American history class or studied total quality management would see the necessity to incorporate those philosophies into the development of software. Software has titles like architect and engineer; however, software efforts fail 50% of the time. The failure rate is attributed to factors that you so eloquently pointed out in your article.

I've implemented "jigs" for every single project I've ever worked on. The fact that more people don't see the need for something like this blows me away! Louis Davidson once said that the system should be designed with no regard for the effort required to implement said design. Having auto-generated code implement specific design details just makes good sense.



Post #998986
Posted Wednesday, October 6, 2010 2:53 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 6:59 AM
Points: 815, Visits: 2,030
In a typical development the schema design is done by a database guy who is obsessed with micro-optimization of individual tables. He fusses over minimizing table size and deciding things like which tables should get synthetic keys or status fields.


Actually I find that all too many schemas have been developed by people who either don't know or don't want to be bothered to follow standard design principles. Designers who are trying to get the design correct are sometimes unfairly labelled as the author has done above, using words like "obsessed" and "fusses." But when the design has issues, the successors to the designer are usually the ones who pay for it.

The decision as to whether a table should receive a synthetic key, for example, are not is very important in an OLTP design. If the table should have been keyed on an existing column or columns, it can easily cause problems down the line.

As for the length of fields, I've seen fields for the city name of varchar(100) and state for varchar(50). Restricting these to a more realistic size is one step towards helping to ensure the proper data gets into the field.

Historical analogies are often risky. Comparing Honda's construction of an engine to applications is shaky. Using a race as a factor shows that under extreme conditions, Honda does better than others. Most applications (or engines for that matter) don't function under extreme conditions. For those applications that do function under extreme conditions, it's even more important to get the design correct, with the understanding that correct changes as the business changes.

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.



Post #999062
Posted Wednesday, October 6, 2010 3:12 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, November 9, 2013 3:12 PM
Points: 2, Visits: 14
This is a good article and certainly the analogy with the motor industry are always pertinent and do get attention.
Obviously being published on SQL Server Central means that readers probably have a natural tendency toward 'bottom-up' systems design where the design of the typical system described in the article starts with a SQL schema before being passed on to a developer who presumably develops the UI etc..

I'm a big believer in the approach promoted by Frederick Brookes in The Mythical Man Month in which the Architect is actually responsible for the User Manual i.e. how the product will work to the end-user. The design of the database is given to the 'surgical team' once the GUI is agreed with the customer. This is very much a 'top-down' approach in contrast to your 'bottom-up' method.

There are some cases where of course 'bottom-up' is a natural means to develop certain line of business (LOB) applications, but with the tools available today for designing 'mock-ups' and allowing customers/end-users to engage in the design process without having to understand Entity Relationship Modelling and SQL schema's, I would never advocate this 'tail wagging the dog' approach for new LOB systems.

Absolutely right however that 'codeless' approaches based on rock-solid foundations is the way to develop todays LOB applications, but I have not been sufficiently impressed by any vendors' offerings that I have ever committed to using such a framework. I never give up hope though, and am always looking for a spark of inspiration and maybe this series will provide that?

Thanks again, TriSys.

Post #999074
Posted Wednesday, October 6, 2010 3:28 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, June 11, 2014 9:54 AM
Points: 912, Visits: 654
No-one seems to be mentioning the elephant in the room here...

If we auto-generate the database and do all the work in higher tiers, what happens to SQL developers? We end up, like the artisans "obsessing" over their cars, replaced but minimum-wage rent-an-operator types to push the 'go' button and perform some simple repetitive tasks.

It may be more efficient, it may be good for the business, but are we really so selfless as to hasten the end of our careers for the good of the industry? On a personal level, I enjoy designing and programming in SQL Server a lot more than I enjoy applying for low paid jobs when my skills are obsolete! I moved from C# to SQL Server because I enjoy the environment more, so the last thing I want to do is eliminate SQL developers!
Post #999082
Posted Wednesday, October 6, 2010 5:07 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, October 29, 2010 10:45 AM
Points: 3, Visits: 4
dave.farmer (10/6/2010)
No-one seems to be mentioning the elephant in the room here... ... the last thing I want to do is eliminate SQL developers!


That is an issue that bears no relevancy with regard to the question whether we can make a huge leap forward in terms of efficiency. I do understand the issue, but this can only be evaluated in terms of re-schooling I guess. In other words, yes, there's an elephant in the room, so let's look how we can get him in the other room, where he's more likely to fit.
Post #999133
Posted Wednesday, October 6, 2010 5:44 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, August 5, 2011 2:11 AM
Points: 1, Visits: 4
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.
Post #999170
Posted Wednesday, October 6, 2010 6:14 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, March 8, 2012 2:54 AM
Points: 14, Visits: 67
I think the Indy 500 analogy is flawed in that not all cars on the road are trying to win the Indy 500...

There's a finite set of problems to solve with racing the Indy 500 - yes there are a lot of elements to consider but eventually the design is going to come to a point where it's as good as it can be. Application development is more like designing a car that can go anywhere and can do anything...

You can streamline the development of applications to some degree, but there will always be a special requirement which doesn't quite fit the tools you have.

Take this for example:

Imagine that every time the Indy 500 came along, before it occurred the racing teams were told that there was going to be a change to the rules of the race. They were given the new rules - maybe there was going to be a set of spikes on the track that the car needed to cross every lap, or maybe the cars were not allowed to stop for new tyres/refuelling...

Each team would come up with a different solution to the problem - it doesn't matter how standard the parts are, their guarantee of success is limited

You can create parts which are reusable, but if those parts just won't fit a solution to a new problem then you are back to the drawing board. Yes some parts can be re-used, but you will almost always find a requirement which needs new designs.

Let's just hope that every time someone asks you to design a car engine it's so that it can win the Indy 500!
Post #999197
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse