October 8, 2010 at 4:01 pm
While 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.
October 10, 2010 at 3:34 am
simon-623950 (10/6/2010)
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.
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 😎
October 16, 2010 at 12:15 am
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?
October 16, 2010 at 6:52 am
chrisl 5993 (10/16/2010)
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?
Send an email to DaveZiffer@ProjectPro.com
October 16, 2010 at 6:54 am
moisixhaf (10/10/2010)
simon-623950 (10/6/2010)
... 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 😎
It may be just an opinion, but it's a great one!
October 20, 2010 at 3:38 am
The 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? 🙂
October 20, 2010 at 9:53 am
Hi,
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.
ken
October 20, 2010 at 10:56 am
Hi 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.
October 27, 2010 at 1:22 am
Great 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.
December 28, 2011 at 7:30 am
David Ziffer (10/6/2010)
timothyawiseman (10/6/2010)
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.
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.
Wow... so much wisdom in this...
Viewing 10 posts - 76 through 84 (of 84 total)
You must be logged in to reply to this topic. Login to reply