Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12345»»»

Where Logic Lives Expand / Collapse
Author
Message
Posted Tuesday, August 23, 2005 9:45 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, September 26, 2012 12:03 PM
Points: 28, Visits: 38
I am sorry if you believe that the article implies that. It wasn't intended to. I am not asking you to buy into anything and I too have cleaned out more databases then I would like to recall because of a lack of referential integrity.

What I am saying is that the database can not and should not decide what is valid data. What is valid data one day may not be the next depending on the needs or wants of the application. Once the application decides what is valid, then yes, the database should be used as a tool to help maintain the integrity of the data.
Post #213004
Posted Tuesday, August 23, 2005 9:56 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, July 27, 2010 7:51 PM
Points: 1,244, Visits: 3
Because for years there has been one application and one database,
encapsulating the data validity and integrity rules in the application has worked successfully. There will continue to be opportunities for these designs.

However, the requirements and resulting architectures are expanding. There are now multiple applications being connected to multiple databases in less tightly coupled ways. The validity and integrity rules must be stored close to the data if there is any chance to manage them cost effectively in this new environment.

Certainly, some of the business logic will be encapsulated in web services that may or may not be closely coupled to the database, but there is now no reason not to keep it close to the database. The design will require careful thought but that's true for any application. Also, the DBAs will have to think more about applications and not just storage management.



Post #213014
Posted Tuesday, August 23, 2005 9:59 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, September 26, 2012 12:03 PM
Points: 28, Visits: 38
Much like the post before, you are confusing business logic with integrity. I agree on the notion of garbage in garbage out, however who are you to decide what is garbage. You can't. The business rules decide what information is important from day to day and those business rule change on the whim of a customer or CEO or News conference or just about anything else the current industrial climate may provide.

As for the set of data, I don't think anyone would argue that getting a set of data out of the database belongs anywhere else. It is what you do with that data that matters. One day you might do something as simple as sorting the data, then next you may have to use the data set in a complex mathmatical formula for derivite trading. You can't do the latter in the database so the data that is in the database shouldn't be specific to that action. Get the set you need and manipulate it programmatically.

As for the comment on overhead, all of those things are cheap and if your application and business logic live in the correct place, then scaling is easy. Take a portion and run here and a portion and run there. You can scale to the hardware available and you have many options for handling network overhead. You can do none of that with you logic living in the database.

Again, in a small scope with limited data, your approach works well. None of these things are issues in a small shop setting.
Post #213016
Posted Tuesday, August 23, 2005 10:09 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, September 26, 2012 12:03 PM
Points: 28, Visits: 38
This is not a microsoft V. Oracle issue. It is a fundamental design issue. Oracle doesn't handle business logic any better than Microsoft or
Sybase or IBM.

The "new" mind set is wrong. I was just at the SQL2005 road show and I asked the developer hosting that tract what the idea behind MS integration of the CLR into the database was. Are they trying to move business logic into the database. His response was that he could now create an application that would run with just the database and IIS using the xml fetures of SQL 2005. His next statement of course was just because you can doesn't mean you should.

Tell me how excellent a place the database is for business logic when you company says they are switching from Oracle to MSSQL or to IBM or any other. The real world dictates a level of flexabilty that business logic in the database does not support.

Please don't think I am encouraging DBAs to shrug off their responsibility. In fact, it is just the opposite. A DBAs responsibiblity to help the developer where the line between business logic and database functionality resides.
Post #213021
Posted Tuesday, August 23, 2005 10:34 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, March 23, 2009 9:44 AM
Points: 179, Visits: 22
This sounds like someone is trying to argue one solution for the whole world.

I'm in the final stages of redesigning a system I inherited and I have to say using the SQL Server for holding the business logic was a saving grace that will meet the future needs of the project and is very flexible. Why thank goodness for SQL? The project started with an MS Access front-end that is still the primary interface. Since then two differnet web sites are using the data and another unit is pulling information out. I should point out that I'm in a very decentralized environment. We don't move from one data server to another. Instead we have anything and everything. Most of the enterprise runs either Oracle, MS SQL, or MySQL but many flavors exist beyond that.

The article was also a good example of an interesting trend. Objrect oriented programming, and even more interestingly design patterns, refactoring, power porgramming, and their ilk, bring up a lot of good ideas. T-SQL is spagetti language but it doesn't mean that we can't apply a lot of the new ideas to what we do. Even if a stored procedure is going to do only one job, take the extra time to avoid hard coding, ask what is really being asked of the stored procedure, apply some of the refactor concepts to the code. My current project has grown as I suspected it might and I'm finding it's very flexible. Even where I've been suprised the stored procedures have been ready to take on the changes (my one complaint is the inability to handle nested insert execute statements).

I'm hoping to expand the scope of one of my systems to the whole enterprise. If and when that time comes, or if another large-scale project comes along, I'll be back in .NET C# or Java and trying to apply all the best practices I can along with other programmers to create a long-lived project. Also, with SQL 2005 I'll start to look for opportunities to move business logic in to C# or Java. But not this current project. The SQL Server for the business layer has been excellent, it's been flexible, and it will scale to cover the range of possibilities.

One size fits all, feh.




Everett Wilson
ewilson10@yahoo.com
Post #213030
Posted Tuesday, August 23, 2005 10:51 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, July 27, 2010 7:51 PM
Points: 1,244, Visits: 3
Well put, Everett.

One may ask whether or not it is good idea to put all the business logic in the application, when a company decides to move from a Java application server to a Microsoft .NET platform.

Businesses may well desire better portability of the application rather than the database, so the better choice would be to keep the business logic in the database. Others want to support several databases, and decide to put the logic in the application.

Oracle has supported object oriented programming in the database for years, first with PL/SQL and then with Java. Microsoft has finally caught up and now enables us to do some sophisticated programming in the database, _if_ we want to. Some systems that I've worked on use that Oracle capability and some don't. It will be the same for applications on Microsoft SQL Server.

If we split the "business logic" into validity/integrity, common must-have business rules, application/work flow rules, and user specific rules, then the placement of the logic should be obvious. That still needs analysis to classify the requirement but its a lot clearer.



Post #213035
Posted Tuesday, August 23, 2005 11:31 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, January 30, 2006 3:20 PM
Points: 34, Visits: 1

Interesting topic.

Of course referential integrity belongs at the database, the database has to be responsible for ensuring the data is as valid as posisble.

Scenario: I put my business logic in my database. I find I have performance issues. I tune, I solve some, I buy more hardware, I solve more issues. Now my customer base tripples (or quadruples) and my database is slow again.  Now how do I scale?

Do I:

A - Buy more hardware - cause we all know how cost effective those 32 proc Itanium 2s can be.

or

B - Spend untold amounts of money re-designing the database for partitioning.

or my preferred method

All "Business logic" goed into the app servers, the only API to the data is through the app servers.  Anyone who touches data without going through the app servers doesn't work for me any more. When my app servers need to scale I buy *more* app servers.  they're cheap, they are web servers, serving web services.

I've worked on too many databases over the years with all this "Business logic" built in and when you hit your performance ceiling the only option is to buy bigger because scaling out is nearly impossible. One company I worked for grew their customer base 20 fold over 4 years. IT has to move FAST to keep up with that level of growth.

 

 




Michael R. Schmidt
Developer
Post #213051
Posted Tuesday, August 23, 2005 11:45 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, March 23, 2009 9:44 AM
Points: 179, Visits: 22
Why does everyone think we all flip companies and work in consulting. With all due respect to the consultants here the majority of projects designed by consultants for the enterprise I work for have either fallen way short or failed. Cutting edge here means proving we can do projects ourselves that are better, using the right technology.

Believe it or not I've only written one piece of code that's ever used more than 5% of the server. The idea of maxing out the hardware eight years ago was a concern, now it's a joke. Every single one of my projects require autehnitcation to use or is still stuck with an MS Access front end, we know the scope. MS Access is a real issue as is migrating to web based APIs and trying to make the life of other units easier.

Think outside the Enterprise/Consultant box.





Everett Wilson
ewilson10@yahoo.com
Post #213060
Posted Tuesday, August 23, 2005 12:47 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, January 30, 2006 3:20 PM
Points: 34, Visits: 1

I can only speak from experience. I was with my last company for four+ years. I worked on the enterprise architecture as the company grew from 1 million to 20 million subscribers and 2000 employees in a central location to 20,000 employees scattered across the country.

I have written many enterprise applications that seriously use (and sometimes abuse) the hardware they run on

In my experience

  1. Putting business logic in the database can cause performance issues
  2. Growth can cause performance issues that cannot be overcome by simply buying hardware
  3. Sometimes you have no choice but to redesign existing architectures - because they were poorly thought out in the first place
  4. Some projects should just be killed because performance was not designed in from the start and retrofitting performance is a bad business decision
  5. Designing systems that scale is easier said than done
  6. Scaling by simply adding a new box (out) is easier than scaling by replacing existing hardware (up)
  7. Designing systems for 24/7/365 (6.9s) is easier said than done
  8. Databases can be designed to scale out but it is not as easy as scaling up, most consultants take the easy road
  9. Management often takes the path of least resistance (what costs me less today) when making project decisions
  10. The first goal of most consultants is to get management to buy off on their ideas – see 9 and think about the implications

Always keep it simple, but not too simple




Michael R. Schmidt
Developer
Post #213092
Posted Tuesday, August 23, 2005 12:54 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, September 15, 2014 5:20 PM
Points: 1,276, Visits: 1,134

There was a thread on one of the SQL newsgroups where we were discussing Google's databases and the hardware they use to run them.  Someone pointed us to a link by one of Google's chief engineers describing their proprietary database and indexing systems designed in-house (as it turns out most of their systems are not SQL-based), and the "throw-away" servers they use to run it all.  Interesting stuff.

I'll see if I can locate the articles and post the links here later.

Post #213097
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse