Board index » delphi » Re: But a fool with a tool is still a fool

Re: But a fool with a tool is still a fool


2006-02-27 05:12:58 AM
delphi193
Jim Cooper writes:
Quote
I'm not. I am opposed to the idea of putting everything in stored
procs.
I never said to put *everything* in stored procedures.
Quote
That can also be a problem, rather than an advantage. You rarely have
to update only the stored proc. Almost always the code that calls it
has to change as well, which means you have to update both the
database and the apps using it.
Our stored procedures perform an action on the data based on business
rules. Rarely does the Delphi code need to change. If you're saying
that this typically happened for you, I am surprised. Sounds like a
pretty bad abstraction, with business logic in multiple areas.
Something I thought you'd be against from the start.
Quote
If you have to update many environments this can easily get out of
sync.
This is true anytime you have more than a single module/executable as
part of your application. You've always got to be sure the modules are
in sync. The same applies to the database schema.
Quote
>Thus, I do not only use stored procedures
There you go, you agree with me
Again, I did not say that we only use stored procedures. Yet, this
seems to be the reason that you replied to my post to debate the
practice of using stored procedures.
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
www.medevolve.com
 
 

Re: But a fool with a tool is still a fool

Jim Cooper writes:
Quote
That's not true. Suppose you need a new parameter to a stored proc,
just for starters. Or you want a stored proc (or a view) to return a
new field. It is very common to have to change the apps too.
Then you're doing it wrong. Default parameter values can be used to
prevent breakage caused by a new parameter. Existing code should not
break by a new column in a table or a view.
Now, if your application is needing to use the new functionality, then
yes, of course there is an application change. However, this part of
the debate seems to be stemming from my comment about fixing *bugs*:
"Also, when fixing bugs, it is a relief to be able to deploy a script
that updates the database instead of recompiling our app server and
possibly our client, and then having to redeploy those to the customer.
A "binary" update requires customer down-time and takes longer. A
script update does not and is usually instantaneous."
New functionality almost always requires every piece of the equation to
be changed.
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
www.medevolve.com
 

Re: But a fool with a tool is still a fool

Jim Cooper writes:
Quote
You were advocating moving your business logic into stored procs. You
said it was because the business logic works directly with the data.
Correct.
Quote
Yet putting logic in stored procs is separating it from data.
Well, I know of no way to embed business logic directly in the data.
Nor do I understand why one would do such a thing.
Anyway, I was referring to the physical barriers between data and
logic. By using stored procedures, the data does not need to be moved
between applications or even between servers. The data can be
manipulated without duplicating it across processes or machines.
Anyway, we're not going to convince each other to change our ways. Nor
do I care to. I only wish you haven't had bad experiences with a
technique that works so well for us.
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
www.medevolve.com
 

Re: But a fool with a tool is still a fool

Quote
If your project required you to anyway, then there were other
things wrong with your project.
Indeed there were. This obsession with having everything in stored procs was one
of the major ones though.
Quote
As one example: Most procedural programmers will resort to cursors to
get something done in a stored procedure.
You're missing my point. it is not to do with how things are done in stored procs
(or views, or triggers). it is about putting anything in them in the first place.
It was the development time that was affected, not performance.
Quote
Nonetheless, if the logic isn't appropriate for a database object, then
don't put it in one.
IME, logic is rarely appropriate for databases. It makes development and
maintenance harder. There has to be a very good reason to override that. There
are such reasons of course, but they should be the exception, not the rule in
most applications.
Cheers,
Jim Cooper
_____________________________________________
Jim Cooper XXXX@XXXXX.COM
Skype : jim.cooper
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
_____________________________________________
 

Re: But a fool with a tool is still a fool

Quote
I never said to put *everything* in stored procedures.
You did say you were going to keep moving your logic into the database. Moving
that way is the wrong way, IME.
Quote
If you're saying that this typically happened for you, I am surprised.
Why? If you have only very minor changes, then you're lucky.
Quote
Sounds like a pretty bad abstraction, with business logic in multiple areas.
Something I thought you'd be against from the start.
I am. You always need some business logic in the app, therefore also putting it
in the database is to be avoided. That is by definition a bad abstraction.
Quote
This is true anytime you have more than a single module/executable as
part of your application. You've always got to be sure the modules are
in sync. The same applies to the database schema.
It's true if you have just the one module.
Quote
Yet, this seems to be the reason that you replied to my post to debate the
practice of using stored procedures.
You were advocating moving your business logic into stored procs. You said it
was because the business logic works directly with the data. Yet putting logic
in stored procs is separating it from data. it is the same as using records and
standalone procedures/functions.
Using only stored procs is your approach taken as far as it will go. It is a
terrible way to develop software. The further away you get from using all stored
procs the better for development and maintenance.
Cheers,
Jim Cooper
_____________________________________________
Jim Cooper XXXX@XXXXX.COM
Skype : jim.cooper
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
_____________________________________________
 

Re: But a fool with a tool is still a fool

Quote
Existing code should not break by a new column in a table or a view.
I didn't say it would break. But there is no point adding new parameters or
fields if you are not going to use them. Therefore the app is likely to change.
Quote
However, this part of the debate seems to be stemming from my
comment about fixing *bugs*:
I was replying to K.Sallee. Your comment was several posts up the tree
Cheers,
Jim Cooper
_____________________________________________
Jim Cooper XXXX@XXXXX.COM
Skype : jim.cooper
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
_____________________________________________
 

Re: But a fool with a tool is still a fool

Quote
You were advocating moving your business logic into stored procs.
Also, I think you have been misquoted. K Sallee quoted you as saying 99% of your
business logic was in the database, and on searching back, I can not find you
saying that. It mislead me, sorry.
Cheers,
Jim Cooper
_____________________________________________
Jim Cooper XXXX@XXXXX.COM
Skype : jim.cooper
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
_____________________________________________
 

Re: But a fool with a tool is still a fool

Quote
Well, I know of no way to embed business logic directly in the data.
It's called object orientation :-)
Cheers,
Jim Cooper
_____________________________________________
Jim Cooper XXXX@XXXXX.COM
Skype : jim.cooper
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
_____________________________________________
 

Re: But a fool with a tool is still a fool

Jim Cooper writes:
Quote
>In fairness, it is quite a bit better if you put the SQL in a const,
>but still nowhere near as easy as just typing the stuff in an SQL
>editor.

Everybody just types it an an SQL editor, don't they?
You're the one arguing for putting it in code. In Delphi, anyway,
doing so requires putting it in quotes, which makes things considerably
more difficult. This is not the case with a DFM.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
All the great TeamB service you've come to expect plus (New!)
Irish Tin Whistle tips: learningtowhistle.blogspot.com
 

Re: But a fool with a tool is still a fool

Quote
But my point is that they really don't have the right to the source
code for the OS APIs and databases like SQL Server, so why should they
have the source for components that wrap that functionality ?
You don't have to explain to me, but "management" often seems to think any
code written by the programmer or used in their project should be included.
The difference is they don't HAVE a choice to get the source from API or
SQL Server but some DO expect the person they are paying to cough up all
the dependent code for the project... Unless it is agreed on prior to work
being completed, it is often a source of contention and delay in getting
paid at least with people I know that do consulting work for the government
and government contractors...
Ryan
 

Re: But a fool with a tool is still a fool

Quote
it is often a source of contention and delay in getting paid
Since delays in getting paid are so common, I have held the source code hostage
before now :-)
Cheers,
Jim Cooper
_____________________________________________
Jim Cooper XXXX@XXXXX.COM
Skype : jim.cooper
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
_____________________________________________
 

Re: But a fool with a tool is still a fool

Quote
Only if you think it is also valid against using any third 3rd party
components. The handling is essentially the same. A client that wants
source code gets source code--just not an exclusive license.
But the entity you are doing work for understands that you are purchasing
the license from someone else. It is harder to convince them that they have
to license YOUR source...
Ryan
 

Re: But a fool with a tool is still a fool

Joanna Carter [TeamB] writes:
Quote
>It's a fools errand to aim to totally decouple a UI from a data
>layer. OTOH, you can try to make the binding as flexible and
>maintainable as

I suggest you take a look at the .NET Binding class, it really does
completely decouple the UI from the data.
Do you mean Binding or BindingContext? BindingContext I have used;
Binding appears to be web service-specific and thus the furthest thing
from decoupling UIs from Data. BindingContext is more or less a
TDataSource with some interesting features and frustrating constraints.
I don't see how it changes the point, though. "Complete" decoupling of
the UI from the DM means your UI doesn't do anything. There is a degree
of coupling which is /wanted,/ and that is the ability to display and
save user data.
The point is that the DM actually can be completely decoupled from the
UI in that it requires no knowledge of the UI *whatsoever* to function,
whereas the UI requires enough knowledge of the DM to at least connect
via a TDataSource, BindingContext, Bold RootHandle, or whatever you
happen to be using for your framework, and render it appropriately for
the user. The DM need neither know nor care whether it will be paired
with a Windows GUI, web page, command line, or whatever interface,
whereas the UI must be designed to work with data structured in such a
way as to determine what will be displayed, what the user can edit, etc.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Useful articles about InterBase development:
blogs.teamb.com/craigstuntz/category/21.aspx
 

Re: But a fool with a tool is still a fool

Jim Cooper writes:
Quote
But they do not add anything that is not already possible in a form.
Whether they are a nicer type of form is not really germane to my
point.
Jim, I understand where you're coming from in an abstract sense, but
in the strictly practical world where you don't want to pull the Forms
unit into your service, DMs make a lot of sense, and it is confusing the
issue to avoid this.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
All the great TeamB service you've come to expect plus (New!)
Irish Tin Whistle tips: learningtowhistle.blogspot.com
 

Re: But a fool with a tool is still a fool

Quote
You're missing my point. it is not to do with how things are done in
stored procs (or views, or triggers). it is about putting anything in
them in the first place. It was the development time that was
affected, not performance.
Does performance not get any weight? Running a stored proc to do something
such as calculate a running total will be MANY order of magnitude faster
than any OPF/client-side anything will ever be. Stored procs are the only
way to get n-tier benefits in a 2 tier system (the stored procs basically
being the logic tier).
Also, the stored proc can be written by the best programmer and consumed
by the not-so-best programmer. Consider the running total again. A db wiz
can crank out a stored proc that hands a newb a number that is the total
instead of having the newb run a query and parse the results.
I personally think as many business rules as possible should be OUT of the
client, preferrably in a 3+ tier situation. If you are targeting multiple
clients that all attach to the same db, such as web, pocketpc, .NET and Win32,
putting the business rules in the framework is redundant, bloats all the
clients, and requires updating ALL the clients instead of just the business
logic tier.
Stored procs have the downside of not being as powerful as a full 3rd tier
and being db dependent. But in an existing application that cannot be ported
overnight to n-tier, stored procs are just about the only other option to
get the benefits of server-side business rules.
Ryan