architecture question

[Jon]

I'm working on a project and the lead developer wants to put all of the
business logic on the database side. He wants the proc to do all of the
logic and create XML on the fly, parse out data, etc, and then return the
final result to the business layer. I pushed back and said that the business
layer should do all of the logic, just have SQL return the data needed and
then have the code do all of the XML creation, parsing of data, etc. I was
told I was wrong and thats not the best practice.
Now, this app can hit the db by a total of 100-500 users a day, and having
the db do all of the processing can have a performance hit. Then he
mentioned something about using temp table in the database side, do a
select, then insert into the temp table, then do a select on the temp table
and do the business logic. I pushed back on that as well..

Now, I'm not a DBA but a developer and I've seen DB's take performance hits
when doing logic such as this on the database side, so my question is, which
would be the best solution for this?

[PS]

"Jon" <Jo*@community. nospam.comwrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..

I'm working on a project and the lead developer wants to put all of the
business logic on the database side. He wants the proc to do all of the
logic and create XML on the fly, parse out data, etc, and then return the
final result to the business layer. I pushed back and said that the
business layer should do all of the logic, just have SQL return the data
needed and then have the code do all of the XML creation, parsing of data,
etc. I was told I was wrong and thats not the best practice.
Now, this app can hit the db by a total of 100-500 users a day, and having
the db do all of the processing can have a performance hit. Then he
mentioned something about using temp table in the database side, do a
select, then insert into the temp table, then do a select on the temp
table and do the business logic. I pushed back on that as well..

Now, I'm not a DBA but a developer and I've seen DB's take performance
hits when doing logic such as this on the database side, so my question
is, which would be the best solution for this?

What does the business layer do with the XML? Is it becoming an object or is
the XML purely data like reporting data?

PS

[robb.andrew]

If your Lead Developer is suggesting this, then I think you need a new
Lead Developer ASAP.

Thanks
Robb Andrew

[Jon]

The developer is generating his own XML to be returned to the C# web
service. Though he's creating a dataset and returning that from his method
which calls the database, he has the stored procedure generating XML within
the proc and then just using that as his dataset to populate Grid,
listboxes, etc.
so the XML isn't being used for reporting, is just being created and then
being used to populate grid, textboxes, labels, listboxes, etc.

he's creating his own dataset XML instead of using the XML format that is
returned when creating a dataset in .NET, though his dataset XML and the one
that .NET returns actually mirror each other, so why is he creating his own
XML I have no idea

"PS" <ec***********@ hotmail.comwrot e in message
news:u4******** ******@TK2MSFTN GP06.phx.gbl...

"Jon" <Jo*@community. nospam.comwrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..

>I'm working on a project and the lead developer wants to put all of the
business logic on the database side. He wants the proc to do all of the
logic and create XML on the fly, parse out data, etc, and then return the
final result to the business layer. I pushed back and said that the
business layer should do all of the logic, just have SQL return the data
needed and then have the code do all of the XML creation, parsing of
data, etc. I was told I was wrong and thats not the best practice.
Now, this app can hit the db by a total of 100-500 users a day, and
having the db do all of the processing can have a performance hit. Then
he mentioned something about using temp table in the database side, do a
select, then insert into the temp table, then do a select on the temp
table and do the business logic. I pushed back on that as well..

Now, I'm not a DBA but a developer and I've seen DB's take performance
hits when doing logic such as this on the database side, so my question
is, which would be the best solution for this?

What does the business layer do with the XML? Is it becoming an object or
is the XML purely data like reporting data?

PS

[Mark Rae [MVP]]

"Jon" <Jo*@community. nospam.comwrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..

Now, I'm not a DBA but a developer and I've seen DB's take performance
hits when doing logic such as this on the database side, so my question
is, which would be the best solution for this?

In addition to what others have replied, I think you have two choices:

1) find another job or, at the very least, ask to be transferred to another
project with a different "lead" (ha! ha!) developer;

2) show this thread to your lead developer and ask for his/her comments.

In fact, I'd probably do both... :-)
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[Jon]

LOL
the good side of this, is that I'm only helping out so they meet their
deadline. I'm not even truly on the project full time, but they brought me
in on this project to help out and kind of over see it to make sure its
going down the correct path technology wise and architecture wise, and so
far, I think its ready for huge downfall performance wise and after going
through some of the code, I'm seeing some other performance issues, as well
as other things.

"Mark Rae [MVP]" <ma**@markNOSPA Mrae.netwrote in message
news:e0******** ******@TK2MSFTN GP02.phx.gbl...

"Jon" <Jo*@community. nospam.comwrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..

>Now, I'm not a DBA but a developer and I've seen DB's take performance
hits when doing logic such as this on the database side, so my question
is, which would be the best solution for this?

In addition to what others have replied, I think you have two choices:

1) find another job or, at the very least, ask to be transferred to
another project with a different "lead" (ha! ha!) developer;

2) show this thread to your lead developer and ask for his/her comments.

In fact, I'd probably do both... :-)
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[sloan]

//he's creating his own dataset XML instead of using the XML format that
is

returned when creating a dataset in .NET, though his dataset XML and the

one

that .NET returns actually mirror each other, so why is he creating his

own

XML I have no idea//

Wow.

Here are some articles:
(mine)
http://sholliday.space s.live.com/Blog/cns!A68482B9628 A842A!139.entry
(pay attention to the dataset vs custom collection performance in the 1.1
code)
http://sholliday.space s.live.com/Blog/cns!A68482B9628 A842A!140.entry
(microsoft)
http://msdn.microsoft.com/library/de...tml/BOAGag.asp

He is misusing XML. Somebody needs to reel that guy in.
Life is too short dude. Find another job if you can. Get on another
project if you can.
This guy is going to set you back so many years, you won't be able to get a
good 'next' job.

If this guy has any (perceived) authority/power, get away from him. (from
your earlier comment that "his way is the best way, period")


"Jon" <Jo*@community. nospam.comwrote in message
news:OY******** ******@TK2MSFTN GP04.phx.gbl...

The developer is generating his own XML to be returned to the C# web
service. Though he's creating a dataset and returning that from his method
which calls the database, he has the stored procedure generating XML

within

the proc and then just using that as his dataset to populate Grid,
listboxes, etc.
so the XML isn't being used for reporting, is just being created and then
being used to populate grid, textboxes, labels, listboxes, etc.

he's creating his own dataset XML instead of using the XML format that is
returned when creating a dataset in .NET, though his dataset XML and the

one

that .NET returns actually mirror each other, so why is he creating his

own

XML I have no idea

"PS" <ec***********@ hotmail.comwrot e in message
news:u4******** ******@TK2MSFTN GP06.phx.gbl...

"Jon" <Jo*@community. nospam.comwrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..

I'm working on a project and the lead developer wants to put all of the
business logic on the database side. He wants the proc to do all of the
logic and create XML on the fly, parse out data, etc, and then return

the

final result to the business layer. I pushed back and said that the
business layer should do all of the logic, just have SQL return the

data

needed and then have the code do all of the XML creation, parsing of
data, etc. I was told I was wrong and thats not the best practice.
Now, this app can hit the db by a total of 100-500 users a day, and
having the db do all of the processing can have a performance hit. Then
he mentioned something about using temp table in the database side, do

a

select, then insert into the temp table, then do a select on the temp
table and do the business logic. I pushed back on that as well..

Now, I'm not a DBA but a developer and I've seen DB's take performance
hits when doing logic such as this on the database side, so my question
is, which would be the best solution for this?

What does the business layer do with the XML? Is it becoming an object

or

is the XML purely data like reporting data?

PS

[sloan]

// In fact, I'd probably do both... :-)//

Amen.


"Mark Rae [MVP]" <ma**@markNOSPA Mrae.netwrote in message
news:e0******** ******@TK2MSFTN GP02.phx.gbl...

"Jon" <Jo*@community. nospam.comwrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..

Now, I'm not a DBA but a developer and I've seen DB's take performance
hits when doing logic such as this on the database side, so my question
is, which would be the best solution for this?

In addition to what others have replied, I think you have two choices:

1) find another job or, at the very least, ask to be transferred to

another

project with a different "lead" (ha! ha!) developer;

2) show this thread to your lead developer and ask for his/her comments.

In fact, I'd probably do both... :-)
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[Mr. Arnold]

"Jon" <Jo*@community. nospam.comwrote in message news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..

LOL
the good side of this, is that I'm only helping out so they meet their
deadline. I'm not even truly on the project full time, but they brought me
in on this project to help out and kind of over see it to make sure its
going down the correct path technology wise and architecture wise, and so
far, I think its ready for huge downfall performance wise and after going
through some of the code, I'm seeing some other performance issues, as well
as other things.

You should remove yourself from the project, and let it go down tubes without you, if possible.

Or become a contractor where you can think to yourself, "It's your bed lay in it, as I am just passing through -- just pay me." :)

If you're up in a NG posting about these kind of issues, then you don't need the stress, as it will kill you early. :)

[Daniel Bass]

Wow, flame on here.
Generally people who don't listen/admit mistakes/take advice are hard to
work with, and under... I know little compared to some of the flyers around
here, but it's that admission that keeps us current/fresh/growing.

"Jon" <Jo*@community. nospam.comwrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..

I'm working on a project and the lead developer wants to put all of the
business logic on the database side. He wants the proc to do all of the
logic and create XML on the fly, parse out data, etc, and then return the
final result to the business layer. I pushed back and said that the
business layer should do all of the logic, just have SQL return the data
needed and then have the code do all of the XML creation, parsing of data,
etc. I was told I was wrong and thats not the best practice.
Now, this app can hit the db by a total of 100-500 users a day, and having
the db do all of the processing can have a performance hit. Then he
mentioned something about using temp table in the database side, do a
select, then insert into the temp table, then do a select on the temp
table and do the business logic. I pushed back on that as well..

Now, I'm not a DBA but a developer and I've seen DB's take performance
hits when doing logic such as this on the database side, so my question
is, which would be the best solution for this?