Separating Business Logic

Question

Separating Business Logic

akhlaq.itexpert

Valued Member

Points: 73
More actions
November 1, 2008 at 4:40 am

#131962

I am basically new sql, so can anyone help me out with this...
How does a query run, when we separate business logic and the actual data. and how does the two servers communicate...

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply

Elisabeth Rédei Hall of Fame Points: 3873 More actions · Answer 1

Hi,

Your question is very generic and it is difficult to tell on what level you want information. You mentioned you are new to SQL Server; what type of environments have you worked in - if you tell us a little bit about that we might be able to say something intelligent about how it works in "our" world 🙂

Also, there are many different places to put business logic and depending on where it is, you would get your data in different ways.

/Elisabeth

elisabeth@sqlserverland.com
MCITP | MCT
http://sqlblog.com/blogs/elisabeth_redei/
http://linkedin.com/in/elisabethredei

akhlaq.itexpert Valued Member Points: 73 More actions · Answer 2

Thanks for your response.......

Well basically i am running sql server 2000 on windows xp

And i want to develop a software for a security company which has multiple client connecting to the server at the same time.

So for learning purpose and to improve efficiency i wanted to divide the data and the business logic

Steve Jones - SSC Editor SSC Guru Points: 736270 More actions · Answer 3

Queries run within SQL Server. You call the query from your application, basically submitting the instruction to SQL like you might to Windows, and then SQL evaluates the query.

Communication is through the protocols setup for SQL Server, T-SQL language over TDS over your network link. Whether you submit a query (SELECT MyID from MyTABLE) or call a stored procedure (EXEC spGetMyTable), the process is the same for your application. SQL either runs the query (after compiling it), or runs the stored procedure.

Your business logic separation is a tradeoff. You can put some logic in stored procedures, but I'd put in the logic required to work with sets of data, not formatting logic or display logic, and not calculations, unless they are done with a set of data. Other types of business stuff should be in your application.

I vote for using stored procedures all the time because they're like methods you call, they can be shared in your application, and they can be tuned. If you submit queries, either hard coded, or SQL you build at runtime, this requires changes to your app for simple tuning issues.