A Programmer in DBA land
 |
(Itai Raz) DB Programmers and DBAs are different animals (though both mammals). They think differently and see the database differently. This article tries to emphasize the differences, written from a programmer's standpoint, while trying to bring out common mistakes that programmers make (and a DBA wouldn't). |
|
|
Key (Please note):
(R) - registration may be required for access at the target site
($) - target site may require paid membership for access to this or other content
Reader Comments: Post Your Comments/Feedback
RE: A Programmer in DBA land
(posted: 5/21/2004 8:37:54 AM)
> "SQL Server had to do everything, including things that no SQL Server should have to worry about like enforcing application business rules ..."
> "You need to put more thought into it and have better reasoning, and if nothing else - the rule of thumb is "don't use the DB machine for anything other than querying the DB"."
----
RE: A Programmer in DBA land
(posted: 5/21/2004 8:40:39 AM)
> "SQL Server had to do everything, including things that no SQL Server should have to worry about like enforcing application business rules ..."
> "You need to put more thought into it and have better reasoning, and if nothing else - the rule of thumb is "don't use the DB machine for anything other than querying the DB"."
----
RE: A Programmer in DBA land
(posted: 5/21/2004 8:42:14 AM)
While it is perhaps true that current DBMS products scale and perform poorly for certain kinds of implementations, enforcing business rules is in fact the historically intended purpose of RDBMS servers. Ideally, a DBMS will enforce the predicates its databases and their relations i.e.(the tables) have been designed for and represent (well or less well). Such predicates should in fact also reflect, (and if reasonably possible using a particular DBMS platform), enforce business rules.
RE: A Programmer in DBA land
(posted: 5/21/2004 8:43:14 AM)
When all business rules are enforced or exist only in application code, one in effect has an application data store, (and not anyhting that could remotely be considered a relational database). Why?
RE: A Programmer in DBA land
(posted: 5/21/2004 8:43:57 AM)
If all business rules specifically exist in application code only, all that is necessacary to corrupt such a "database" i.e.(data integrity) is activity (Inserts, Updates, and Deletes) from a connection by another application created by individuals unaware of and / or or unable / unwilling to implement the rules of the original application correctly. {Consider that many environments will come to have multiple applications that interface with a given database and perform Inserts, Updates,
RE: A Programmer in DBA land
(posted: 5/21/2004 8:44:35 AM)
and Deletes, and it may become clear why enforcing no rules within a DBMS can lead to data corruption.}
While it is perhaps true that current DBMS products scale and perform poorly for certain kinds of implementations, enforcing business rules is in fact the historically intended purpose of RDBMS servers. Ideally, a DBMS will enforce the predicates its databases and their relations i.e.(the tables) have been designed for and represent (well or less well). Such predicates should in fact also
RE: A Programmer in DBA land
(posted: 5/21/2004 8:44:53 AM)
reflect, (and if reasonably possible using a particular DBMS platform), enforce business rules.
RE: A Programmer in DBA land
(posted: 5/21/2004 1:19:27 PM)
I like the theme of this article: that there is a substantial amount of specialized expertise needed to use a DB effectively, which many programmers do not have. Two oversimplifications are made though, one is the business-rule point made by others, and the second concerns cursors. The generic advice to avoid cursors would be better stated as: 1. Avoid cursors when set operations are possible, and 2. Avoid cursors that return rows to the client, and 3. Avoid scrollable and updatable cursors.
|
