Of J. Merrill
>Sent: Friday, September 23, 2005 2:25 AM
>To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
>Subject: Re: [ADVANCED-DOTNET] Business logic
>
>I've become a believer in never have developers write SPs by hand (in an
>editor). Instead, we write programs (in the language o
. Merrill
Sent: Friday, September 23, 2005 2:25 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
I've become a believer in never have developers write SPs by hand (in an
editor). Instead, we write programs (in the language of the app) that
construct the SP
Hi Frans ,
> -Original Message-
> From: Unmoderated discussion of advanced .NET topics.
[mailto:ADVANCED-
> [EMAIL PROTECTED] On Behalf Of Frans Bouma
> Sent: Thursday, 22 September 2005 4:29 PM
> To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
> Subject: Re: [ADVANCED-DOTN
. . .;-)
Jeff
-Original Message-
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of J. Merrill
Sent: Thursday, September 22, 2005 4:55 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
I've become a believer in
I've become a believer in never have developers write SPs by hand (in an
editor). Instead, we write programs (in the language of the app) that
construct the SPs (as strings) and cause them to be created. This lets you
have SPs that trivially do things like changing the datatypes of parameters
>This is IMHO not true. The simple reason for this is that once you have a
proc which is used by multiple apps, you can't
>hange it if it needs a new parameter/different type/updated resultset,
because it will break a lot of apps, and perhaps these
>aren't written in-house. So what do you do? You a
11:29 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
> In environments with lots of applications accessing the
> same database they also add more value. (Though this can
> backfire in case of testing changes to stored procs )
This is
> In environments with lots of applications accessing the
> same database they also add more value. (Though this can
> backfire in case of testing changes to stored procs )
This is IMHO not true. The simple reason for this is that once you have
a proc which is used by multiple apps
is another story entirely).
>
> Sure there are some absolutes, but fairly few. Adaptability is the
key to
> survival, both in this business and in nature. The only way to adapt
is
> to
> keep an open mind.
>
> OK, I'll stop being evangelical and dogmatic now . .
d .NET topics.
> [mailto:[EMAIL PROTECTED] On Behalf Of J. Merrill
> Sent: Tuesday, September 13, 2005 13:54
> To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
> Subject: Re: [ADVANCED-DOTNET] Business logic
>
> At 01:12 PM 9/13/2005, Steve Johnson wrote
> >On 9/13/05, Alex Smotri
> But Google bears out your assertion that it's more commonly
> used for Administrator today -- there are an order of
> magnitude more hits for DBA as administrator than analyst.
> Still, the first Google hit on "jargon DBA"
> says "Short for Database Administrator, Database Analyst or
> Database A
Mike,
What off list email should we use?
From: Unmoderated discussion of advanced .NET topics. on behalf of Mike A
Sent: Thu 9/15/2005 11:27 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
Well stated Jeff. Given your
survival, both in this business and in nature. The only way
> to adapt is to keep an open mind.
>
> OK, I'll stop being evangelical and dogmatic now . . .
>
> Jeff
>
> -Original Message-
> From: Unmoderated discussion of advanced .NET topics.
> [mailto:[EMAIL
Yes it is unfortunate that I played into your prejudice of database
administrators/analysts or whatever by letting my contempt show, and I was
wrong for saying developers with out some or many (especially since I still
am one). My comments do not imply that I don't care about the application
code.
this business and in nature. The only way
> to adapt is to keep an open mind.
>
> OK, I'll stop being evangelical and dogmatic now . . .
>
> Jeff
>
> -Original Message-
> From: Unmoderated discussion of advanced .NET topics.
> [mailto:[EMAIL PROTECTED] On Beha
y get
more experienced.
-Original Message-
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff Little
Sent: Thursday, September 15, 2005 11:31 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
Quite a thread. Le
;ll stop being evangelical and dogmatic now . . .
Jeff
-Original Message-
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Frans Bouma
Sent: Thursday, September 15, 2005 9:31 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET]
> >> > What I find hard to understand is that you really don't
> >> > give a
> >> > about the application your procs are part of, as it seems.
> >> > That's
>
> >> Not sure how you got that out my comments. I said I had no
>
> Here's exactly how we all got that out of your comments:
>
Tim,
>> > What I find hard to understand is that you really don't give a
>> > about the application your procs are part of, as it seems. That's
>> Not sure how you got that out my comments. I said I had no
Here's exactly how we all got that out of your comments:
>> Sure it does si
Not sure how you got that out my comments. I said I had no control over
the application code only the database code. I am not a manager. I send
articles to the other developers, try to educate them, complain repeatedly
to management and constantly push for better development process.
>
> Sure it does since the developers have to submit their stored
> procs to me to be applied ;-) I have no control what they do
> in their crappy code but I have almost total control over
> what gets applied to the database. If I allowed dynamic SQL
> in my stored procs (which requires permissions
Sure it does since the developers have to submit their stored procs to me
to be applied ;-) I have no control what they do in their crappy code but
I have almost total control over what gets applied to the database. If I
allowed dynamic SQL in my stored procs (which requires permissions to the
un
On 9/14/05, Alex Smotritsky <[EMAIL PROTECTED]> wrote:
> I read a while back Google had 8,000 servers in their farm.
Right. And not one of them is a database, and there are no SANs. They
have learned the scaling means commodity hardware and custom software,
using RAM as their primary storage syste
From: "Kamen Lilov" <[EMAIL PROTECTED]>
And to the previous poster who claimed A standed for Analyst...
DBA = DataBase Administrator
Well, I feel certain that it stood for Analyst at some point in the past.
But Google bears out your assertion that it's more commonly used for
Administrator toda
Its good design practice to factor out SQL
statements/queries out of your middle tier business
logic objects/components. Improves the testability and
optimization of the SQL statements among other
benefits that others have alluded to:)
Shapiro...
"The best way to predict the future is to invent it
Alex,
>> We brought in a $90/hr sql server expert. He cleaned out the deadlocks in
...
[del]
>> This is what a great dba can do. This particalur guy however wouldn't be
good
The guy you're describing isn't even remotely linked to the DBA job. He's
what I like to call "a database expert" - a cons
erated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Steve Welborn
Sent: Wednesday, September 14, 2005 7:25 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
>>The most important person on any development project
is usually a
> Just because you can accomplish some of these through parameterized sql
> does not invalidate the reasons for using stored procedures.
You proposed SQL Injection as a reason for using stored procedures
OVER dynamic SQL. I've stated that parameterized dynamic SQL is just
as safe as stored proced
I don't think you are going to make any points by posting poor code
examples. If that were the case I could code up crappy business objects
all day long to argue against your views which I do not totally agree with
and also do not totally disagree with. Your view seems to be that there is
only on
> > 1. Security - with stored procedures you do not have to give
> > permissions to the underlying tables. This is becoming a bigger issue
> > with Sarbanes-Oxley, HIPAA and other privacy regulations.
>
> Valid.
And even that is only halfway valid. You can remove update/delete/insert
permissions
Just because you can accomplish some of these through parameterized sql
does not invalidate the reasons for using stored procedures. Additionally,
if I limit access to my data through stored procedures I am guaranteed
these things. If not I have to trust others to do the right thing,
especially i
> 1. Security - with stored procedures you do not have to give permissions to
> the underlying tables. This is becoming a bigger issue with
> Sarbanes-Oxley, HIPAA and other privacy regulations.
Valid.
> 2. Cached query plans.
Bogus. Query plans for parameterized SQL are cached.
> 3. SQL inj
It depends on how you develop you application. A good design will be able to
take that in stride with only changes in the application data layer. By
using adapters and factory classes you can simply keep a small stock of them
for each implementation. Need to add MySQL - its not a problem, just
> Frans Bouma wrote:
>
> > And with this, all data-access is done, without any db
> specific stuff.
> > This means that you can have a single set of domain
> objects, bl tier
> > and gui and just a bunch of db specific generated projects
> (or mapping
> > files if you use an o/r mapper which uses
> > > Database independence is a fallacy.
> >
> > +1 to that.
>
>No it's not. With the proper O/R mapper, true db independence is a
> reality.
+1 to _THAT_. I'm using WilsonORMapper (and have used nHibernate and
hand-rolled ones too -- sorry Frans) and my application is totally DB
agnos
From: "Chip Dunning" <[EMAIL PROTECTED]>
I do not understand why so many thing database independence
is a fallacy?
Well, there are at least two separate scenarios here:
1. The WhizBang(TM) product or project originally used Oracle but must now
use SQL Server instead.
2. The WhizBang(TM) produ
From: "Andrew Gayter" <[EMAIL PROTECTED]>
For example - developers cannot write efficient SQL statements
without an integral knowledge of how the DB will optimize the query
and which indexes have been set up. A good DBA will know this
and be able to create SPs which are efficient and work correc
-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
> I wouldn't necessarily call database languages primitive. They are a
> specialized tool for set based logic. Set based logic is something few
> developers understand. How much extra unindexed data will you bri
There are more reasons than this for writing stored procedures.
1. Security - with stored procedures you do not have to give permissions to
the underlying tables. This is becoming a bigger issue with
Sarbanes-Oxley, HIPAA and other privacy regulations.
2. Cached query plans.
3. SQL injection.
Frans Bouma wrote:
> And with this, all data-access is done, without any db specific
> stuff. This means that you can have a single set of domain objects,
> bl tier and gui and just a bunch of db specific generated projects
> (or mapping files if you use an o/r mapper which uses mapping files,
> n
In the environment work, we have have an Application
Development DBA and real DBA:)
Shapiro
--- Chip Dunning <[EMAIL PROTECTED]> wrote:
> Then you have not worked with a real DBA. I would no
> more call someone that
> came in to just run backups and check validations a
> DBA than I would called
September 14, 2005 10:33 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
I do not understand why so many thing database independence is a
fallacy? A good design is flexible enough to absorb the redesign of any
one component without failing. If you cannot
> Isolating the database to libraries is usually the best
> approach. Database independence is being able to move to
> different DB's without code change outside the database.
> This is often a pipedream IMHO.
only if you use stored procedures or hand-written SQL ;)
"I've been involved in systems (Dell for example) where we've placed ALL
logic into Oracle packages to improve performance. Reason for doing this
was
because the application was simply pulling data into the middle-tier
massaging it and then putting it back into a different set of tables. We
decided
eaker
->-Original Message-
->From: Unmoderated discussion of advanced .NET topics.
->[mailto:[EMAIL PROTECTED] On Behalf Of Chip Dunning
->Sent: Wednesday, September 14, 2005 10:33 AM
->To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
->Subject: Re: [ADVANCED-DOTNET] Business logic
->
-&
Then you have not worked with a real DBA. I would no more call someone that
came in to just run backups and check validations a DBA than I would called
the person switching backup tapes a Network Administrator. Depending on the
business you will often find these higher-level people preforming th
27; - but it
worked :-)
A
-Original Message-
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Kamen Lilov
Sent: 14 September 2005 15:03
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
Andrew,
One message li
Apologies in advance, but what has that to do with business logic?
I'm sure you could get the best industry professionals in the world, for
instance on Dbs as you say, but if the whole architecture isn't right then
problems of various kinds can occur in the short, medium and large term.
Those tha
>Franklin Gray
> ->Sent: Tuesday, September 13, 2005 6:10 PM
> ->To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
> ->Subject: Re: [ADVANCED-DOTNET] Business logic
> ->
> ->""No technical or functional requirement, just a business
> ->one. This is the very na
>>The most important person on any development project
is usually a DBA.
>>Good DBAs can save a project - simply because THEY
know what they're doing
>>and can create a performing database and schema.
I venture to say a great developer doesn't need a
DBA for anything because
they would have the
> >> The most important person on any development project is usually a DBA.
> Good DBAs can save a project - simply because THEY know what they're doing and
> can create a performing database and schema.
>
> Unlike a developer or a system architect, who actually knows
> some worthless and lowly tec
Andrew,
One message like this and you've already started to ruin the great
reputation Developmentor has always had among senior developers.
>> The most important person on any development project is usually a DBA.
Good DBAs can save a
>> project - simply because THEY know what they're doing and c
ransmission. If verification is required please request
> a
> hard-copy version. Although we routinely screen for viruses, addressees
> should check this e-mail and any attachments for viruses. We make no
> representation or warranty as to the absence of viruses in this e-mail or
> any attachments.
>
om: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Timothy Flory
Sent: 14 September 2005 12:53
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
I wouldn't necessarily call database languages primitive. They are a
s
I wouldn't necessarily call database languages primitive. They are a
specialized tool for set based logic. Set based logic is something few
developers understand. How much extra unindexed data will you bring over
to the middle tier for processing? Also as far as change control goes it
is easier
-DOTNET] Business logic
>> Isn't one of Oracle's pitches (the validity of which I do not pretend to
know) that
>> you can use an "Oracle grid" consisting of large numbers of commodity
servers
>> in order to "infinitely" scale your database?
Don'
> From: "Shawn Wildermuth" <[EMAIL PROTECTED]>
>
> > Database independence is a fallacy.
>
> +1 to that.
No it's not. With the proper O/R mapper, true db independence is a
reality.
FB
===
This list is hosted by DevelopMentor® http://www.d
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED]
On Behalf Of Franklin Gray
Sent: Tuesday, September 13, 2005 12:47 PM
>
> I'm now on a project where they use Oracle and since Oracle allows
> more of a development capability, they've put the business l
From: "Franklin Gray" <[EMAIL PROTECTED]>
""No technical or functional requirement, just a
business one. This is the very nature of how business gets done and ends
up
with a myriad of different architectures"
Wouldn't this be an example as to why not to put the BL in the DB? Never
know when s
day, September 13, 2005 6:10 PM
->To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
->Subject: Re: [ADVANCED-DOTNET] Business logic
->
->""No technical or functional requirement, just a business
->one. This is the very nature of how business gets done and
->ends up with a myriad
VP, MCSD.NET, Author and Speaker
->-Original Message-
->From: Unmoderated discussion of advanced .NET topics.
->[mailto:[EMAIL PROTECTED] On Behalf Of
->Franklin Gray
->Sent: Tuesday, September 13, 2005 6:10 PM
->To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
->Subject: Re: [
""No technical or functional requirement, just a
business one. This is the very nature of how business gets done and ends
up
with a myriad of different architectures"
Wouldn't this be an example as to why not to put the BL in the DB? Never
know when somebody is going to say "lets switch".
=
Tuesday, September 13, 2005 5:08 PM
->To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
->Subject: Re: [ADVANCED-DOTNET] Business logic
->
->Kudos for this post! I am always inclined to chuckle at the
->various initiatives that are undertaken to "standardize"
->development, ar
>> Isn't one of Oracle's pitches (the validity of which I do not pretend to
know) that
>> you can use an "Oracle grid" consisting of large numbers of commodity
servers
>> in order to "infinitely" scale your database?
Don't know if many people have done this, but I'm one of those guys who's
actuall
nmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Chip Dunning
Sent: Tuesday, September 13, 2005 4:28 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
Not a big fan of ZDNet, but this (http://blogs.zdnet.com/Ou/?p=71) talks
a
Not a big fan of ZDNet, but this (http://blogs.zdnet.com/Ou/?p=71) talks
about Oracle's Grid computing.
I guess if you thrown an infinite amount of cash you can get Oracle Grid to
infinitly scale, but I worked for 2 years in an Oracle Grid/Cluster
environment and it was nice - but nothing that
At 01:12 PM 9/13/2005, Steve Johnson wrote
>On 9/13/05, Alex Smotritsky <[EMAIL PROTECTED]> wrote:
>>
>> As much business logic as possible should go in the db whether it be
>> oracle
>> or sql server with middle tier objects acting as brokers between the db
>> and
>> the interface.
>>
>
>I disagre
Business rules are the ones changing more than anything else - I'm not sure
changing your database will be the best place for this!
On 9/13/05, Jeff Ferguson <[EMAIL PROTECTED]> wrote:
>
> > As much business logic as possible should go in the db
> > whether it be oracle or sql server with middl
Chip Dunning wrote:
> I am a programmer - thus I tend to find the idea of keeping business
> logic in the primitive database languages available abhorrant. I like
> to keep the ability to completely ripout the business logic if
> necessary have have it affect the other parts as little as possible.
It depends highly on where those making the decisions are coming from.
Programmers tend to favor n-teir approaches where tasks are divided into
buckets that preform their assigned role. DBAs tend to push as much as
possible into the database engine letting the rest of the app to handle the
inte
Adding to the debate just a little, the conclusion I've come to for 4-tier.
The client is obvious and should be wholly disconnected from the business
tier. The business tier, totally disconnected from the data tier can sit
anywhere: at the client, the data server or another server, all without any
LOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
It is perhaps unfortunate that Oracle corporation does not view itself
as being in the RDBMS business. It views itself as being in the
application business (witness their recent acquisitions of various ERP
vendors).
In a way, I can see thei
On 9/13/05, Alex Smotritsky <[EMAIL PROTECTED]> wrote:
>
> As much business logic as possible should go in the db whether it be
> oracle
> or sql server with middle tier objects acting as brokers between the db
> and
> the interface.
>
I disagree. Putting more logic in the only tier that won't
-Original Message-
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff Ferguson
Sent: Tuesday, September 13, 2005 1:04 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
> As much business logic as possibl
sage-
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff Ferguson
Sent: Tuesday, September 13, 2005 1:04 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
> As much business logic as possible should go in the db
My work has taught me rather the opposite of what Alex and Rob are
advocating.
Indeed Oracle PL/SQL is a generation ahead of the clumsy misunderstanding
called TransactSQL. Still, I believe you shouldn't put too much BL into the
database itself.
Examples of good things to put into the DB (and, i
ussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff Ferguson
Sent: Tuesday, September 13, 2005 1:04 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
> As much business logic as possible should go in the db whether it be
> oracle or
> As much business logic as possible should go in the db
> whether it be oracle or sql server with middle tier objects
> acting as brokers between the db and the interface.
Fair enough, but there may also be disadvantages to that approach.
* If business logic is in the database, then the user c
It is perhaps unfortunate that Oracle corporation does not view itself
as being in the RDBMS business. It views itself as being in the
application business (witness their recent acquisitions of various ERP
vendors).
In a way, I can see their point of view -- what useful, real-world
application doe
IMHO. u should always try to push as much processing as possible down to
the data engine. this is MOST efficient being that the data transfered
between levels is minimized.
Redeye
- Original Message -
From: "Franklin Gray" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, September 13, 2005 12:46
As much business logic as possible should go in the db whether it be oracle
or sql server with middle tier objects acting as brokers between the db and
the interface.
-Original Message-
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Franklin Gr
81 matches
Mail list logo
