Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Writing Nearly Codeless Apps: Part 1


Writing Nearly Codeless Apps: Part 1

Author
Message
David Ziffer
David Ziffer
SSC-Enthusiastic
SSC-Enthusiastic (147 reputation)SSC-Enthusiastic (147 reputation)SSC-Enthusiastic (147 reputation)SSC-Enthusiastic (147 reputation)SSC-Enthusiastic (147 reputation)SSC-Enthusiastic (147 reputation)SSC-Enthusiastic (147 reputation)SSC-Enthusiastic (147 reputation)

Group: General Forum Members
Points: 147 Visits: 203
Comments posted to this topic are about the item Writing Nearly Codeless Apps: Part 1
kenambrose
kenambrose
SSC-Enthusiastic
SSC-Enthusiastic (181 reputation)SSC-Enthusiastic (181 reputation)SSC-Enthusiastic (181 reputation)SSC-Enthusiastic (181 reputation)SSC-Enthusiastic (181 reputation)SSC-Enthusiastic (181 reputation)SSC-Enthusiastic (181 reputation)SSC-Enthusiastic (181 reputation)

Group: General Forum Members
Points: 181 Visits: 663
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



mriffey
mriffey
Forum Newbie
Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)

Group: General Forum Members
Points: 6 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
emmchild
emmchild
SSC Journeyman
SSC Journeyman (80 reputation)SSC Journeyman (80 reputation)SSC Journeyman (80 reputation)SSC Journeyman (80 reputation)SSC Journeyman (80 reputation)SSC Journeyman (80 reputation)SSC Journeyman (80 reputation)SSC Journeyman (80 reputation)

Group: General Forum Members
Points: 80 Visits: 408
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.



RonKyle
RonKyle
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1570 Visits: 3398
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.



garry-1010072
garry-1010072
Forum Newbie
Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)

Group: General Forum Members
Points: 6 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.
dave.farmer
dave.farmer
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1164 Visits: 772
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!
bernard.libbrecht
bernard.libbrecht
Forum Newbie
Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)

Group: General Forum Members
Points: 5 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.
simon-623950
simon-623950
Forum Newbie
Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)

Group: General Forum Members
Points: 3 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.
Charles Pockert
Charles Pockert
Grasshopper
Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)Grasshopper (18 reputation)

Group: General Forum Members
Points: 18 Visits: 69
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!
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search