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 2, 2005 1:57 PM
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
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/mdillon/wherelogiclives.asp
Post #206626
Posted Tuesday, August 23, 2005 1:08 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, December 5, 2008 12:47 PM
Points: 4, Visits: 3

Mike,

Can you elaborate a little more about your statement that databases (or DBMSs) don't scale?  I don't really know how the DBMSs themselves are designed so it's a big question in my mind as to how someone like eBay or Amazon or heaven forbid Google designs their database systems.

Thanks,

Gery

Post #212856
Posted Tuesday, August 23, 2005 1:24 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Friday, October 7, 2011 5:16 AM
Points: 88, Visits: 4

The article implies that logic to maintain integrity should not reside in the database.  I couldn't disagree more.  You either put logic in the database, or you clean garbage out.  It's as simple as that.  I've cleaned up too many databases to buy into this.

You can argue that logic that transforms data belongs in the middle or presentation tier, and in most cases you would be correct, but logic that guarantees that the database can only contain valid information, whether it include declarative referential integrity constraints, multiplicity constraints, check constraints, or procedural constraints (triggers), is an integral part of the database and as such shouldn't be separate.

 




Brian
MCDBA, MCSE+I, Master CNE
Post #212859
Posted Tuesday, August 23, 2005 2:51 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Tuesday, May 6, 2014 5:51 AM
Points: 6,266, Visits: 2,028

If you've been to a Databases 101 course with a minimally decent teacher the FIRST thing you learn is GARBAGE IN- GARBAGE OUT. You must(is your responsability to) ensure your data integrity as close as possible to the data.

Yes some business logic that is extremelly intricate may be a candidate for that middle tear but those are not as commom as very well defined rules that are ussually simple and can and in my opinion should be implemented in the Database.

When you need to perform an operation with a SET of data there is no better software out there than a relational engine.

Now repeat this with me Application Server Scale at expense of more servers + statless logic + network overhad!!!! there is no win-win solution you need to know what to put where and that's one of the reason we get paid for

It was an interesting point of view and a food for thought one.

I just have a different approach

Cheers!

  




* Noel
Post #212870
Posted Tuesday, August 23, 2005 8:12 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
Databases do scale and Microsoft would argue that they can scale as well as Oracle, but it takes skill to do this well. As Microsoft SQL Server has risen in capabilities toward Oracle's level, so has the need for better planning and engineering.

Databases are excellent places to contain business logic; it HAS to be close to the data and it all has to be centralized to be well managed. That's the key idea of OOD and, the next level up, SOA. That's why Oracle had to put Java in its database and Microsoft had to put .NET into its database. These are key enablers of this new mindset.

The larger and more complex systems being implemented on Microsoft platforms are demanding a new level of sophistication. The database is at the heart of these sophisticated systems.

DBAs cannot shrug this off and let application developers take all the responsibility for scaling and complexity.



Post #212908
Posted Tuesday, August 23, 2005 8:44 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Wednesday, July 9, 2014 9:37 AM
Points: 2,553, Visits: 567
Flexibility decreases as logic increases.....true but that's exactly what placing the logic in the db is supposed to do...guard the db from the user who only seems hellbent on trying to throw trash in...

....has become a tangled web of different logic for different things that are so specific that they can’t be used for anything else.......why would you want to use a db designed for a specific application with specific requirements, specific purpose ie..custom built be used for anything else ?!

...when you need to add features that allow you to do business in another country......surely something like this would be identified even before the db is a gleam in the developer's eye - isn't this why we suffer through the pain of zillions of meetings with user groups who are determined to contradict each other in their requirements for the same application....?!?!

Mike - when your dad said "..you never have to go out looking for trouble, it will find you on its own.”...I think he really meant that if you don't use all the wonderful features of sql server to your advantage and design the db accordingly, trouble will not only find you, it may well come chasing after you with a club in hand.... - seriously though, are you saying that no logic should reside in the db or that logic should reside in moderation....couldn't quite get a sense of where you stand in all this?!?!?!








**ASCII stupid question, get a stupid ANSI !!!**
Post #212943
Posted Tuesday, August 23, 2005 9:15 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, August 4, 2009 2:56 PM
Points: 8, Visits: 12
Totally agree.  Business logic should stay with the application code.  This allows for total flexibility.  For different situation, just compile in a different class, or use a different xml file, or a different property file.  Database is for data.  Leave it that way.


Post #212973
Posted Tuesday, August 23, 2005 9:20 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Wednesday, July 16, 2014 12:52 AM
Points: 21,385, Visits: 9,601
So your programmers never fail to validate data and there's no way that a new data import procedure can screw up the data????????
Post #212978
Posted Tuesday, August 23, 2005 9:23 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
jkli,

That's ok for small, static, narrowly targeted applications. That has been Microsoft's heritage and there will continue to be such applications.

However, Microsoft is targeting larger, more complex applications that serve broader audiences in large enterprises. Corporations are demanding such applications be hosted on Microsoft technology for cost reasons. The DBAs and developers that can step up to these will be much more successful than those working on small systems.

Databases are not just for data anymore.



Post #212980
Posted Tuesday, August 23, 2005 9:42 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, August 4, 2009 2:56 PM
Points: 8, Visits: 12

Peter,

I happen to work on a very large, enterprise project and through my over 20 year career worked on many large, enterprise projects.  Exactly for the reason of enterprise projects, business logic should stay with the application, as you never know which part of the business logic requires changing. 

 

With object oriented languages like c++, java, c#, as well as others, we can use design patterns to handle complex business logics, place them in different packages for different situations.  The new sql server has ability to use c# to write stored procedures.  However, it is not easy to apply design patterns as it is still stored procedures,  and to use packaging to allow for the flexibility of changing business logic on the fly.

 




Post #212999
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse