Data Layer architecture

Edwin Yip wrote:

Hi,

Of course the send option is the best. I thinkd the architecture
should looks like:

presentation layer
|
business logic layer
|
data access layer
Check MS's PetShop sample, you will get your idea clearer.
If there's *ONE* sample which is badly constructed and horrible coded
it's the MS Petshop sample. It's solely developed to show how fast .NET
can be, not how to write an application in an n-tier fashion.

FB

"laimis" <si*****@iit.edu> ???
news:uE**************@TK2MSFTNGP12.phx.gbl ???...
Hey guys,

I just recently got introduced to data mappers (DTO mapper). So now
I have a SqlHelper being used by DTOMapper and then business layer
is using DTOMapper when it needs to persist object to database or
load them back. Everything is working nicely so far. My question
is, is it OK practice to use DTOMapper rfom the presentation layer?
For instance, if I want to present in HTML format the list of
entries in my database, should I use DTOmapper from the
presentation, or instead use Entries collection method which
internally uses DTOMapper.

THe second option sounds more cleaner and more seperated. Just want
to see what you guys think...

Thanks!

Laimis

Edwinyeah's NUnitPartner
Automatic NUnit test case generation!
http://www.freewebs.com/edwinyeah/

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

Nov 17 '05 #6

Edwin Yip wrote:

Hi,

Of course the send option is the best. I thinkd the architecture
should looks like:

presentation layer
|
business logic layer
|
data access layer
Check MS's PetShop sample, you will get your idea clearer.
If there's *ONE* sample which is badly constructed and horrible coded
it's the MS Petshop sample. It's solely developed to show how fast .NET
can be, not how to write an application in an n-tier fashion.

FB

"laimis" <si*****@iit.edu> ???
news:uE**************@TK2MSFTNGP12.phx.gbl ???...
Hey guys,

I just recently got introduced to data mappers (DTO mapper). So now
I have a SqlHelper being used by DTOMapper and then business layer
is using DTOMapper when it needs to persist object to database or
load them back. Everything is working nicely so far. My question
is, is it OK practice to use DTOMapper rfom the presentation layer?
For instance, if I want to present in HTML format the list of
entries in my database, should I use DTOmapper from the
presentation, or instead use Entries collection method which
internally uses DTOMapper.

THe second option sounds more cleaner and more seperated. Just want
to see what you guys think...

Thanks!

Laimis

Edwinyeah's NUnitPartner
Automatic NUnit test case generation!
http://www.freewebs.com/edwinyeah/

Nov 17 '05 #7

There are a couple of ways of using Data Transfer Objects. By Mapper, do
you mean the Assembler pattern?

To see how to use the DTO concept in .Net, see:
http://msdn.microsoft.com/library/de...pedDataSet.asp

For details on how to use typed datasets as a DTO, see
http://adoguy.com/content.aspx?id=sa...apter/chapter1
and
http://www.codeproject.com/dotnet/In...romDataSet.asp

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"laimis" <si*****@iit.edu> wrote in message
news:uE**************@TK2MSFTNGP12.phx.gbl...

Hey guys,

I just recently got introduced to data mappers (DTO mapper). So now I have
a SqlHelper being used by DTOMapper and then business layer is using
DTOMapper when it needs to persist object to database or load them back.
Everything is working nicely so far. My question is, is it OK practice to
use DTOMapper rfom the presentation layer? For instance, if I want to
present in HTML format the list of entries in my database, should I use
DTOmapper from the presentation, or instead use Entries collection method
which internally uses DTOMapper.

THe second option sounds more cleaner and more seperated. Just want to see
what you guys think...

Thanks!

Laimis

Nov 17 '05 #8

Hey guys,

I just recently got introduced to data mappers (DTO mapper). So now I have
a SqlHelper being used by DTOMapper and then business layer is using
DTOMapper when it needs to persist object to database or load them back.
Everything is working nicely so far. My question is, is it OK practice to
use DTOMapper rfom the presentation layer? For instance, if I want to
present in HTML format the list of entries in my database, should I use
DTOmapper from the presentation, or instead use Entries collection method
which internally uses DTOMapper.

THe second option sounds more cleaner and more seperated. Just want to see
what you guys think...

Thanks!

Laimis

Nov 17 '05 #9

laimis

After looking at the links provided by Nick (and enterprise patterns
book), I realized that I have misunderstood DTO pattern. What I really
needed is a mapper actually.

My desing now looks like this:

UI Layer:
aspx, user controls, pages, etc.

Business:
Various business objects

Data Layer:
DbMapper (is able to translate IDataReader or DataSet to business
object)
DbProvider (has sql code and procedures)
SqlHelper (and MsSqlHelper) for direct access to db

DbMapper is accessed through IDbMapper interface. It is loaded using
factory method which sets up the mapper with appropriate DbProvider.
DbProvider uses uses either SqlHelper or MsSqlHelper (depending on what
db is used) to access the db.

I will probably have seperate DbProviders for MsSql and MySql because
queries and some calls are different and then IDbMapper will be using
IDbProvider.

I would be very very thankful if someone with experience could comment
on my design. My main goal was to move the sql out of business objects
and isolate sql from actual translation of datasets or datareaders to
business objects.

Let me know what you think,

thanks,

Laimis
Data Layer:

Nick Malik [Microsoft] wrote:

There are a couple of ways of using Data Transfer Objects. By Mapper, do
you mean the Assembler pattern?

To see how to use the DTO concept in .Net, see:
http://msdn.microsoft.com/library/de...pedDataSet.asp

For details on how to use typed datasets as a DTO, see
http://adoguy.com/content.aspx?id=sa...apter/chapter1
and
http://www.codeproject.com/dotnet/In...romDataSet.asp

Nov 17 '05 #10

laimis

There are a couple of ways of using Data Transfer Objects. By Mapper, do
you mean the Assembler pattern?

To see how to use the DTO concept in .Net, see:
http://msdn.microsoft.com/library/de...pedDataSet.asp

For details on how to use typed datasets as a DTO, see
http://adoguy.com/content.aspx?id=sa...apter/chapter1
and
http://www.codeproject.com/dotnet/In...romDataSet.asp

Nov 17 '05 #11

your design looks quite solid.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"laimis" <si*****@iit.edu> wrote in message
news:u9**************@TK2MSFTNGP14.phx.gbl...

After looking at the links provided by Nick (and enterprise patterns
book), I realized that I have misunderstood DTO pattern. What I really
needed is a mapper actually.

My desing now looks like this:

UI Layer:
aspx, user controls, pages, etc.

Business:
Various business objects

Data Layer:
DbMapper (is able to translate IDataReader or DataSet to business object)
DbProvider (has sql code and procedures)
SqlHelper (and MsSqlHelper) for direct access to db

DbMapper is accessed through IDbMapper interface. It is loaded using
factory method which sets up the mapper with appropriate DbProvider.
DbProvider uses uses either SqlHelper or MsSqlHelper (depending on what db
is used) to access the db.

I will probably have seperate DbProviders for MsSql and MySql because
queries and some calls are different and then IDbMapper will be using
IDbProvider.

I would be very very thankful if someone with experience could comment on
my design. My main goal was to move the sql out of business objects and
isolate sql from actual translation of datasets or datareaders to business
objects.

Let me know what you think,

thanks,

Laimis
Data Layer:

Nick Malik [Microsoft] wrote:
There are a couple of ways of using Data Transfer Objects. By Mapper, do
you mean the Assembler pattern?

To see how to use the DTO concept in .Net, see:
http://msdn.microsoft.com/library/de...pedDataSet.asp

For details on how to use typed datasets as a DTO, see
http://adoguy.com/content.aspx?id=sa...apter/chapter1
and
http://www.codeproject.com/dotnet/In...romDataSet.asp

Nov 17 '05 #12

After looking at the links provided by Nick (and enterprise patterns
book), I realized that I have misunderstood DTO pattern. What I really
needed is a mapper actually.

My desing now looks like this:

UI Layer:
aspx, user controls, pages, etc.

Business:
Various business objects

Data Layer:
DbMapper (is able to translate IDataReader or DataSet to business object)
DbProvider (has sql code and procedures)
SqlHelper (and MsSqlHelper) for direct access to db

DbMapper is accessed through IDbMapper interface. It is loaded using
factory method which sets up the mapper with appropriate DbProvider.
DbProvider uses uses either SqlHelper or MsSqlHelper (depending on what db
is used) to access the db.

I will probably have seperate DbProviders for MsSql and MySql because
queries and some calls are different and then IDbMapper will be using
IDbProvider.

I would be very very thankful if someone with experience could comment on
my design. My main goal was to move the sql out of business objects and
isolate sql from actual translation of datasets or datareaders to business
objects.

Let me know what you think,

thanks,

Laimis
Data Layer:

Nick Malik [Microsoft] wrote:
There are a couple of ways of using Data Transfer Objects. By Mapper, do
you mean the Assembler pattern?

To see how to use the DTO concept in .Net, see:
http://msdn.microsoft.com/library/de...pedDataSet.asp

For details on how to use typed datasets as a DTO, see
http://adoguy.com/content.aspx?id=sa...apter/chapter1
and
http://www.codeproject.com/dotnet/In...romDataSet.asp

Nov 17 '05 #13

> I would be very very thankful if someone with experience could comment

on my design. My main goal was to move the sql out of business objects
and isolate sql from actual translation of datasets or datareaders to
business objects.

Before you introduce extra layers of complexity, read this:
http://grumpyoldprogrammer.myblogsit...13/851175.html

Looks like everyone (including me) has to learn that the hard way though.
:)

Greetings,
Wessel

Nov 17 '05 #14

> I would be very very thankful if someone with experience could comment

on my design. My main goal was to move the sql out of business objects
and isolate sql from actual translation of datasets or datareaders to
business objects.

Nov 17 '05 #15

laimis

Before you introduce extra layers of complexity, read this:
http://grumpyoldprogrammer.myblogsit...13/851175.html
Looks like everyone (including me) has to learn that the hard way
though. :)

Well I think what this article and many other books, posts about
software design, all underline one key software design rule: consider
tradeoffs of your decisions.

And maybe to clarify, I am not thinking for every business layer class
to have a corresponding data layer class and other crazy stuff. Not at
all :) I just want that procedure or sql call out of my business
objects. It is ugly and adds of bunchy of ugle sql code or procedures
mixed up with business logic implemented in C#.

Nov 17 '05 #16

Please don't feed the trolls.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"laimis" <si*****@iit.edu> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

Before you introduce extra layers of complexity, read this:
http://grumpyoldprogrammer.myblogsit...13/851175.html
Looks like everyone (including me) has to learn that the hard way though.
:)

Well I think what this article and many other books, posts about software
design, all underline one key software design rule: consider tradeoffs of
your decisions.

And maybe to clarify, I am not thinking for every business layer class to
have a corresponding data layer class and other crazy stuff. Not at all :)
I just want that procedure or sql call out of my business objects. It is
ugly and adds of bunchy of ugle sql code or procedures mixed up with
business logic implemented in C#.

Nov 17 '05 #17

> Please don't feed the trolls.

Thanks for that? Laimis put the spirit of the post right when he said
"consider tradeoffs of your decisions".

One of the projects I worked on failed because it had too many layers.
The design was all by the books (Microsoft's "Designing Component-Based
Applications" by Mary Kirtland.) It was hard work to develop.

When we finally had the first working version, the bugfixes and
requirement changes started to come in. For each requirement, we had to
change the database, data access, business logic, and presentation
layers. Then we had to write a converter for the database and all of the
messages in the queues. Then we had to write an installer to update the
application. We had made a wrong tradeoff for this particular project;
the time required for the extra layers wasn't worth it. The project was
cancelled.

On a next project, I used only two layers and dropped the message queues.
Development speed was amazing. We were responsive to the customer's
requests, and able to deliver on time.

A good learning experience though.

Greetings,
Wessel

Nov 17 '05 #18

On Sun, 24 Jul 2005 11:53:09 +0200, "Wessel Troost"
<no*****@like.the.sun> wrote:

One of the projects I worked on failed because it had too many layers.
The design was all by the books (Microsoft's "Designing Component-Based
Applications" by Mary Kirtland.)
Very predictable. It is a suicide to follow trade media books written
by any programmer without a clue on formal data management theory.

The trade media publications lack almost any content quality control
and they are very endogamic. Any new nonsense written by a dare false
expert might be automatically propagated (regurgited) to many other
publications, and after a while it could be accepted as dogma by many
no brainer coders. This stuff happens everyday.
On a next project, I used only two layers and dropped the message queues.
Development speed was amazing. We were responsive to the customer's
requests, and able to deliver on time.

A good learning experience though.

But it is a very expensive learning way. Everyone with a clue on data
management theory knows that the business logic must be ensured by the
DBMS and not by the applications (this is taught in the first week of
any serious database course).

Applications must be the presentation layer of an Information System
(something known since the 60's), and we should keep away from all the
business objects trade media garbage.

Congratulations for your blog.
Regards

Nov 17 '05 #19

> Congratulations for your blog.

Thanks for the compliment, but I could only wish to write a blog like
that. I'm just one of its readers.

Greetings,
Wessel

Nov 17 '05 #20

Alfredo Novoa wrote:

On Sun, 24 Jul 2005 11:53:09 +0200, "Wessel Troost"
<no*****@like.the.sun> wrote:
On a next project, I used only two layers and dropped the message
queues. Development speed was amazing. We were responsive to the
customer's requests, and able to deliver on time.

A good learning experience though.
But it is a very expensive learning way. Everyone with a clue on data
management theory knows that the business logic must be ensured by the
DBMS and not by the applications (this is taught in the first week of
any serious database course).

Hmm, then my serious db courses at the uni weren't very 'serious'
then!

NO law states that BL has to be IN the DBMS.

BL is a data-consuming tier, not part of the relational model. If you
pick up a book by Nijssen or Halpin, or Yourdon for that matter, you'll
learn that relational theory, e.g. the schema setup in your DBMS, is
not a theory which states anything about business rules. It only gives
context to the data its format it defines, no logic whatsoever.
Applications must be the presentation layer of an Information System
(something known since the 60's), and we should keep away from all the
business objects trade media garbage.

One researcher once made a list of how many client-server
architectures there were, he came to 7 if I'm not mistaken. Your
proposed setup is one of them, but far from the only one.

What you suggest is typically a big-iron box in the basement, and thin
clients connecting to it, where all the software is written by DBA's.

I hope I don't have to drop the word 'scalability' on you.

FB

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

Nov 17 '05 #21

> Hmm, then my serious db courses at the uni weren't very 'serious'

then!
If they were anything like the ones I took, they were largely about theory
and in small part about simplified, idealistic practice.
BL is a data-consuming tier, not part of the relational model. If you
pick up a book by Nijssen or Halpin, or Yourdon for that matter, you'll
learn that relational theory, e.g. the schema setup in your DBMS, is
not a theory which states anything about business rules. It only gives
context to the data its format it defines, no logic whatsoever.
I'd have to disagree with that. The relational model can enfore business
rules-- like, at most one customer per order, every order has a unique
identifier, and it's obligatory to fill in the postal code for an order.

Besides, there's more about a database than the relational model.
- It can restrict access for certain people (only managers can see other
people's salary; only senior help desk officers can re-assign tickets; ...)
- It can restrict status transitions by controlling the change through a
stored procedure (like moving an order from InProgress to Fullfilled;
requiring a resolve-date when a help desk ticket is closed; ...)
- It provides a fool-proof way to ensure there's only one version of the
business logic in production :)

Such safeguards in the database are simple to develop, and more fool-proof
than safeguards at another level. I think it's safe to say enforcing BL
in the database is a "best practice".
What you suggest is typically a big-iron box in the basement, and thin
clients connecting to it, where all the software is written by DBA's.

I hope I don't have to drop the word 'scalability' on you.

Would you agree with the statement that in the vast majority of projects,
scalability is not an issue?

Greetings,
Wessel

Nov 17 '05 #22

On Mon, 25 Jul 2005 01:01:30 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

But it is a very expensive learning way. Everyone with a clue on data
management theory knows that the business logic must be ensured by the
DBMS and not by the applications (this is taught in the first week of
any serious database course).
Hmm, then my serious db courses at the uni weren't very 'serious'
then!

If you don't know that I am afraid they were a little disaster.
Nothing rare, by the way.
NO law states that BL has to be IN the DBMS.
No law, but it is a well stablished principle in the database
community. You might check the first chapter of any popular
introductory book like Date, Elmasri & Navathe, Korth & Silverschatz,
etc.
BL is a data-consuming tier, not part of the relational model. If you
pick up a book by Nijssen or Halpin, or Yourdon for that matter, you'll
learn that relational theory, e.g. the schema setup in your DBMS, is
not a theory which states anything about business rules.
None of them is an expert on relational theory.

You should read Codd, Date or Fabian Pascal to get a clue. Business
rules support is one of the main components of any database model.

In a 1981 paper entitled "Data Models in Database Management" Codd
defined a data model to consist of a combination of three components:

1. A collection of data object types, which form the basic building
blocks for any database that conforms to the model;

2. A collection of general integrity rules (business rules), which
constraint the set of occurrences of those object types that can
legally appear in any such database;

3. A collection of operators, which can be applied to such object
occurrences for retrieval and other purposes

Source:

http://www.amazon.com/exec/obidos/tg...12941?v=glance
It only gives
context to the data its format it defines, no logic whatsoever.
The Relational Model is nothing but a direct application of set theory
and predicate logic to the data management field. If you don't know
that then you know practically nothing about it.

Codd's genial insigth was to use the mathematical logic for the
business logic. The Relational Model is a small branch of mathematical
logic.

Applications must be the presentation layer of an Information System
(something known since the 60's), and we should keep away from all the
business objects trade media garbage.

One researcher once made a list of how many client-server
architectures there were, he came to 7 if I'm not mistaken. Your
proposed setup is one of them, but far from the only one.

My proposed "setup" might have infinite architectural forms. Client
Server is only an special kind of distributed system. A distributed
DBMS composed by zillions of servers still is a single DBMS.
What you suggest is typically a big-iron box in the basement, and thin
clients connecting to it, where all the software is written by DBA's.
All the business logic code is written by DBA's or database
programmers, but all presentation logic still needs to be written by
application programmers.
I hope I don't have to drop the word 'scalability' on you.

Scalability has nothing to do with this. There are many ways to scale
a well designed Information System where all the business logic is
ensured by the DBMS.
Regards

Nov 17 '05 #23

On Mon, 25 Jul 2005 10:42:43 +0200, "Wessel Troost"
<no*****@like.the.sun> wrote:

BL is a data-consuming tier, not part of the relational model. If you
pick up a book by Nijssen or Halpin, or Yourdon for that matter, you'll
learn that relational theory, e.g. the schema setup in your DBMS, is
not a theory which states anything about business rules. It only gives
context to the data its format it defines, no logic whatsoever.
I'd have to disagree with that. The relational model can enfore business
rules-- like, at most one customer per order, every order has a unique
identifier, and it's obligatory to fill in the postal code for an order.

Any DBMS must be able to enforce any business rule. If not, it is not
a DBMS.

For instance MS Jet is not a DBMS, it is a primitive file processor.
Besides, there's more about a database than the relational model.
Indeed. Besides what you said, the Relational Model says nothing about
the objects you store in the tuple attributes, but they must be
validated by the DBMS either.

Here is a very interesting interview:

http://www.dbmsmag.com/int9410.html
- It can restrict status transitions by controlling the change through a
stored procedure (like moving an order from InProgress to Fullfilled;
requiring a resolve-date when a help desk ticket is closed; ...)
It could be done with a declarative constraint too.
- It provides a fool-proof way to ensure there's only one version of the
business logic in production :)
Something essential.
Such safeguards in the database are simple to develop, and more fool-proof
than safeguards at another level. I think it's safe to say enforcing BL
in the database is a "best practice".

It is the only sensible practice.
Regards

Nov 17 '05 #24

In message <61********************************@4ax.com>, Alfredo Novoa
<al***********@hotmail.com> writes

2. A collection of general integrity rules (business rules)

General integrity rules != business rules.

--
Steve Walker

Nov 17 '05 #25

On Mon, 25 Jul 2005 12:16:22 +0100, Steve Walker
<st***@otolith.demon.co.uk> wrote:

In message <61********************************@4ax.com>, Alfredo Novoa
<al***********@hotmail.com> writes
2. A collection of general integrity rules (business rules)

General integrity rules != business rules.

General integrity rules are business rules.

Business rules are usually divided in constraint rules and derivation
rules, but any business rule might be considered as a constraint rule.

If we declare that an invoice total is the sum of all invoice line
subtotals, this is a derivation rule, but we are also constrainting
(to one) the possible values of the "Total" derived attribute.

On the other hand, structural business rules are clearly constraint
rules.

See this:

http://www.businessrulesgroup.org/brghome.htm
http://www.businessrulesgroup.org/brgdefn.htm
http://www.alphora.com/12Rules-Date.pdf
Regards

Nov 17 '05 #26

In message <s6********************************@4ax.com>, Alfredo Novoa
<al***********@hotmail.com> writes

On Mon, 25 Jul 2005 12:16:22 +0100, Steve Walker
<st***@otolith.demon.co.uk> wrote:
In message <61********************************@4ax.com>, Alfredo Novoa
<al***********@hotmail.com> writes
2. A collection of general integrity rules (business rules)
General integrity rules != business rules.

General integrity rules are business rules.

They are arguably a subset of business rules. Personally, I prefer to
see them as an implementation specific requirement of a particular class
of structured storage, but then I consider databases a necessary and
largely unavoidable evil.
Business rules are usually divided in constraint rules and derivation
rules, but any business rule might be considered as a constraint rule.

You're looking at this from a very data-centric point of view. This is
perfectly reasonable given that you approach system design from that
angle, but it isn't the only way of doing so.

--
Steve Walker

Nov 17 '05 #27

On Mon, 25 Jul 2005 13:36:13 +0100, Steve Walker
<st***@otolith.demon.co.uk> wrote:

General integrity rules are business rules.
They are arguably a subset of business rules. Personally, I prefer to
see them as an implementation specific requirement of a particular class
of structured storage

Such a view confuses the logical level with the implementation level.

Integrity rules are logical level artifacts. They are independent to
the implementation and the storage mechanisms. They are also
independent to the language used to declare them (SQL for instance).

Although SQL is far from being relational, but that is another story.
, but then I consider databases a necessary and
largely unavoidable evil.
A database is a set of facts that represents some aspects of the
business.

Any organized set of facts is a database.

Again a database is a logical artifact independent to the
implementation and the physical storage.

Did you mean DBMS, perhaps?

Business rules are usually divided in constraint rules and derivation
rules, but any business rule might be considered as a constraint rule.

You're looking at this from a very data-centric point of view.

Business Information Systems are very data-centric by nature.
This is
perfectly reasonable given that you approach system design from that
angle, but it isn't the only way of doing so.

Do you know any other reasonible way of doing so?
Regards

Nov 17 '05 #28

In message <6n********************************@4ax.com>, Alfredo Novoa
<al***********@hotmail.com> writes

On Mon, 25 Jul 2005 13:36:13 +0100, Steve Walker
<st***@otolith.demon.co.uk> wrote:
General integrity rules are business rules.

They are arguably a subset of business rules. Personally, I prefer to
see them as an implementation specific requirement of a particular class
of structured storage

Such a view confuses the logical level with the implementation level.

Integrity rules are logical level artifacts. They are independent to
the implementation and the storage mechanisms. They are also
independent to the language used to declare them (SQL for instance).

A logical data model, distinct from any class model, is not always a
necessary analysis if a relational database is not being used for data
storage. Conversely, if an object orientated system needs to use a
relational database for storage, a logical data model of some sort will
always be required.

, but then I consider databases a necessary and
largely unavoidable evil.

A database is a set of facts that represents some aspects of the
business.

Any organized set of facts is a database.

Again a database is a logical artifact independent to the
implementation and the physical storage.

Did you mean DBMS, perhaps?

Picky. Did you really not understand what I meant, or are you being
pedantic for the sake of it?

Business rules are usually divided in constraint rules and derivation
rules, but any business rule might be considered as a constraint rule.

You're looking at this from a very data-centric point of view.

Business Information Systems are very data-centric by nature.

They often are. Frequently the complexity comes from the required
behaviour of the system rather than from the structure of the data.

This is
perfectly reasonable given that you approach system design from that
angle, but it isn't the only way of doing so.

Do you know any other reasonible way of doing so?

What, as opposed to designing a database and sticking some simple forms
on the front of it? Well, yes I do, but you must also be well aware of
them.

--
Steve Walker

Nov 17 '05 #29

On Mon, 25 Jul 2005 17:26:46 +0100, Steve Walker
<st***@otolith.demon.co.uk> wrote:

A logical data model, distinct from any class model, is not always a
necessary analysis if a relational database is not being used for data
storage.
Here is the big problem!

A class model is nothing but an obsolete network model. The Object
Data Model simply does not exist.

To hide (encapsulate) a relational database behind an application
memory network database is a great blunder, and it is the essence of
all the business objects junk.

Besides this, if we remove the business rules from the centralized
DBMS and scatter them over the applications then we have a recipe for
a disaster like the one that Wessel mentioned.

I am aware of many other project failures due to the blunderous
"business objects approach".
Conversely, if an object orientated system needs to use a
relational database for storage, a logical data model of some sort will
always be required.
A logical data model of some sort is always required to represent
data, but a class model is one of the worst sorts.

A class model is evidently a data model, but a very primitive and
obsolete one: a network model. An object reference is nothing but a
pointer, and data is processed navegating pointer labyrinths using
procedural code. A return to the stone age.

Did you mean DBMS, perhaps?

Picky. Did you really not understand what I meant, or are you being
pedantic for the sake of it?

I can't understand you if you are so sloppy. What you said does not
make any sense.

Business Information Systems are very data-centric by nature.

They often are.

Indeed, the 100% of the times.
Frequently the complexity comes from the required
behaviour of the system rather than from the structure of the data.
The behaviour comes from the business rules, structural or not.

This is
perfectly reasonable given that you approach system design from that
angle, but it isn't the only way of doing so.

Do you know any other reasonible way of doing so?

What, as opposed to designing a database and sticking some simple forms
on the front of it?

Simple or complex but never on the front of a database, on the front
of a DBMS. A DBMS is an essential middle layer between databases and
applications.

BTW a DBMS is also an application server.
Well, yes I do, but you must also be well aware of
them.

I am aware about they don't exist.
Regards

Nov 17 '05 #30

Sorry Alfredo, having had a look at your posts to other newsgroups I'm
now aware that this something of a hobby horse for you. I've had these
arguments before, at great length, and enormous tedium, but then I was
being paid to do so. I understand that you have absolutely no time for
the object orientated approach to building software, so I shall
respectfully say that you are entitled to your opinion. I'm not being
drawn into an argument about this here.

All I will say is that I don't understand why you have the slightest
interest in a C# newsgroup, since your preferred mode of development can
be achieved perfectly well using PHP or some other simple scripting
language.

--
Steve Walker

Nov 17 '05 #31

On Mon, 25 Jul 2005 18:52:14 +0100, Steve Walker
<st***@otolith.demon.co.uk> wrote:

Sorry Alfredo, having had a look at your posts to other newsgroups I'm
now aware that this something of a hobby horse for you.
I simply try to combat the simpletonism and misinformation to the
little extent of my possibilities where I find it. Unfortunately there
are many people a lot more perseverant than me doing exactly the
contrary.
I understand that you have absolutely no time for
the object orientated approach to building software
The object orientated approach is for building applications, not for
for managing data. Applications are only a part of an Information
System.

Joe Celko posted this many times:

-------
Many years ago, the INCITS H2 Database Standards Committee(nee ANSI
X3H2 Database Standards Committee) had a meeting in Rapid City, South
Dakota. We had Mount Rushmore and Bjarne Stroustrup as special
attractions. Mr. Stroustrup did his slide show about Bell Labs
inventing C++ and OO programming for us and we got to ask questions.

One of the questions was how we should put OO stuff into SQL. His
answer was that Bells Labs, with all their talent, had tried four
different approaches to this problem and come the conclusion that you
should not do it. OO was great for programming but deadly for data.
--------
All I will say is that I don't understand why you have the slightest
interest in a C# newsgroup, since your preferred mode of development can
be achieved perfectly well using PHP or some other simple scripting
language.

I am developing a new generation RDBMS using C#
Regards

Nov 17 '05 #32

Alfredo Novoa wrote:

On Mon, 25 Jul 2005 01:01:30 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:
But it is a very expensive learning way. Everyone with a clue on data >> management theory knows that the business logic must be
ensured by the >> DBMS and not by the applications (this is taught in
the first week of >> any serious database course).

Hmm, then my serious db courses at the uni weren't very 'serious'
then!
If you don't know that I am afraid they were a little disaster.
Nothing rare, by the way.

Ah, a 'holier than thou'-person.

NO law states that BL has to be IN the DBMS.

No law, but it is a well stablished principle in the database
community. You might check the first chapter of any popular
introductory book like Date, Elmasri & Navathe, Korth & Silverschatz,
etc.

I think you confuse some things. First of all, a lot of books about
database theory are rather old, say, the 80-ies. In that time, having
distributed applications was a non-existing phenomenon. Of course the
rules were described to be inside the RDBMS, as the RDBMS was located
on the mainframe / mini.

However times changed. In a distributed environment, business rules
aren't necessarily placed inside the RDBMS, as there's no real need to
do that.

I haven't heard any argument in favor of doing so from you yet.

Oh, and the 'database community' is largely formed by DBA's. Of course
they don't want to give up their role as BL developer as it would
degrade their position in the company/organisation.

BL is a data-consuming tier, not part of the relational model. If
you pick up a book by Nijssen or Halpin, or Yourdon for that
matter, you'll learn that relational theory, e.g. the schema setup
in your DBMS, is not a theory which states anything about business
rules.

None of them is an expert on relational theory.

You should read Codd, Date or Fabian Pascal to get a clue. Business
rules support is one of the main components of any database model.

Oh dear, I don't have a clue, according to mr. Alfredo 'Holier than
thou' Novoa.

Business rules aren't the same as integrity rules. If you would come
off your high horse, you'd learn I do agree with placing data-integrity
rules inside the database. Though it's something else to place behavior
in the database as well. After all, a relational model defines static
rules, but not behavior.
In a 1981 paper entitled "Data Models in Database Management" Codd
defined a data model to consist of a combination of three components:
in 1981, the only computing model available was the mainframe/mini
setup: large box in the corner/basement, and terminals. There was no
other solution than that. No n-tier development, just a single tier,
located on the server.
1. A collection of data object types, which form the basic building
blocks for any database that conforms to the model;

2. A collection of general integrity rules (business rules), which
constraint the set of occurrences of those object types that can
legally appear in any such database;
BL rules != integrity rules!
3. A collection of operators, which can be applied to such object
occurrences for retrieval and other purposes
which you can also define as commands to the RDBMS. After all, code
INSIDE the rdbms, is located there physically but is ran AGAINST the
RDBMS engine the same way as external code is ran against it.
Source:

http://www.amazon.com/exec/obidos/tg...12941?v=glance
It only gives
context to the data its format it defines, no logic whatsoever.
The Relational Model is nothing but a direct application of set theory
and predicate logic to the data management field. If you don't know
that then you know practically nothing about it.

Dear Alfredo Novoa, why do you even take the time to lecture me about
relational model theory? Because you want to show the world you're the
only person who knows it all?

the relational model doesn't define predicate logic, it defines
relations between attributes and relationships between relations.
Codd's genial insigth was to use the mathematical logic for the
business logic. The Relational Model is a small branch of mathematical
logic.

the relational model offers you the structure but not the behavior.

geezz.. this is like explaining OO to a C-fetisjist.

Applications must be the presentation layer of an Information System >> (something known since the 60's), and we should keep away
from all the >> business objects trade media garbage.

One researcher once made a list of how many client-server
architectures there were, he came to 7 if I'm not mistaken. Your
proposed setup is one of them, but far from the only one.

My proposed "setup" might have infinite architectural forms. Client
Server is only an special kind of distributed system. A distributed
DBMS composed by zillions of servers still is a single DBMS.

No, your only possible setup is: everything in the RDBMS and on top of
that a thin client with solely presentation functionality. Any business
rule is in teh RDBMS after all.
What you suggest is typically a big-iron box in the basement, and
thin clients connecting to it, where all the software is written by
DBA's.

All the business logic code is written by DBA's or database
programmers, but all presentation logic still needs to be written by
application programmers.

aha, all business logic is written by DBA's, there we have the
background of your story. Check out the 'A' in DBA. It doesn't stand
for progrAmmer.

Writing procedural code in SQL is stupid also. SQL is a set-oriented
language and interpreted (as the statements by themselves are handled
by optimized code). So writing procedural BL code in SQL is a paradigm
clash between prodecural code and set-oriented code.

BL code is procedural by nature, not set-oriented. This is also why BL
code is better off in its own environment. The 'distribution of
concerns' is then also done in a better way, as BL code consumes, and
the rdbms delivers.

After all, your BL code written in SQL statements is ran ON TOP of
your relational model anyway.

I hope I don't have to drop the word 'scalability' on you.

Scalability has nothing to do with this. There are many ways to scale
a well designed Information System where all the business logic is
ensured by the DBMS.

If you have an E10000 with your large oracle db on it, and because you
store all your logic inside that oracle instance as well, the server
needs expanding, you have more trouble than when your middle tier with
your BL needs expanding, as you then just place a tiny new server into
your BL sever farm and everything is OK.

But I disgress. You think you know it all, we're stupid, you're not.
Well, Alfredo Novoa, have fun.

FB
--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

Nov 17 '05 #33

Alfredo Novoa wrote:

On Mon, 25 Jul 2005 18:52:14 +0100, Steve Walker
<st***@otolith.demon.co.uk> wrote:
Sorry Alfredo, having had a look at your posts to other newsgroups
I'm now aware that this something of a hobby horse for you.
I simply try to combat the simpletonism and misinformation to the
little extent of my possibilities where I find it. Unfortunately there
are many people a lot more perseverant than me doing exactly the
contrary.

Well, the only think you're achieving is that you look like some
60-year old gnu-emacs lover who comes in to tell us that VS.NET with
intellisense is the root of all evil.

What's also stunning is your serious lack of listening / reading
capabilities and the talent to realize we all have been to uni/college
to some degree and have studied the same dreaded books you have studied
and perhaps even way more than you have done.

What I find intriguing is that you didn't mention Yourdon in any way
in your lecturing comments. Not suprisingly of course, as Yourdon went
the OO route and thus became one of the Dark Side-members.

I also have failed to see even ONE argument why ALL (not some, but
ALL) business rules and LOGIC (!) has to be written in code which is
placed INSIDE the RDBMS.

Even though when code inside an RDBMS runs ON TOP OF the database it
targets.

I understand that you have absolutely no time for
the object orientated approach to building software

The object orientated approach is for building applications, not for
for managing data. Applications are only a part of an Information
System.

... and data is only data. Information is something else.
OO is just a way to write software, or better: to look at how to
divide responsibility over what to write to increase re-usability and
structure.
Joe Celko posted this many times:
-------
Many years ago, the INCITS H2 Database Standards Committee(nee ANSI
X3H2 Database Standards Committee) had a meeting in Rapid City, South
Dakota. We had Mount Rushmore and Bjarne Stroustrup as special
attractions. Mr. Stroustrup did his slide show about Bell Labs
inventing C++ and OO programming for us and we got to ask questions.

One of the questions was how we should put OO stuff into SQL. His
answer was that Bells Labs, with all their talent, had tried four
different approaches to this problem and come the conclusion that you
should not do it. OO was great for programming but deadly for data.
--------

OO == data+behavior. I appreciate Celko's work for SQL, but I always
have the feeling he has a certain bias against anything not SQL.

All I will say is that I don't understand why you have the
slightest interest in a C# newsgroup, since your preferred mode of
development can be achieved perfectly well using PHP or some other
simple scripting language.

I am developing a new generation RDBMS using C#

a new 'generation' RDBMS? Ah no wonder you want everything INSIDE the
rdbms!. But what's a new generation? Post-relational database system
like uniVerse, with 3D tables? Or plain old boring RDBMS like we all
know so not really 'new generation' ?

FB

ps: databases and RDBMS-es are great, I really think so, but don't
overreact. You IMHO overreact how great they are and what they SHOULD
do. Not everyone has the same opinion as you do, nor are you the only
one who knows it all.
--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

Nov 17 '05 #34

Wessel Troost wrote:

Hmm, then my serious db courses at the uni weren't very 'serious'
then!
If they were anything like the ones I took, they were largely about
theory and in small part about simplified, idealistic practice.

of course, but still very serious.

BL is a data-consuming tier, not part of the relational model. If
you pick up a book by Nijssen or Halpin, or Yourdon for that
matter, you'll learn that relational theory, e.g. the schema setup
in your DBMS, is not a theory which states anything about business
rules. It only gives context to the data its format it defines, no
logic whatsoever.

I'd have to disagree with that. The relational model can enfore
business rules-- like, at most one customer per order, every order
has a unique identifier, and it's obligatory to fill in the postal
code for an order.

True, but so can other code.

It's not as if the data inside the database isn't storable anymore if
I don't place a check-constraint on a table or add a trigger somewhere.
Also it doesn't have to conflict with my relational model.

You see, I can define business rules according to my functional
research I did on the business PROCESS I have to automate. I then
analyse which entities are used in the process, how they relate and
define a relational model from that (niam or other abstract modeling
technique for example). I can then decide to enforce static rules in
the RDBMS, using FK/Check or default constraints and other rules,
perhaps flexible rules, to be applied in the application logic. If
someone says "that's wrong!", I'd like to know why.

You can for example state that the application logic with the BL rules
+ the data in the database form your application. However where the
application logic is stored is not important, nor where the data is
stored. It's just moving a border: first it's: "everthing inside the
RDBMS is correct", then it's "everthing below (including) the BL tier
is correct. It just depends on how you look at it.
Besides, there's more about a database than the relational model.
- It can restrict access for certain people (only managers can see
other people's salary; only senior help desk officers can re-assign
tickets; ...)
sure
- It can restrict status transitions by controlling the
change through a stored procedure (like moving an order from
InProgress to Fullfilled; requiring a resolve-date when a help desk
ticket is closed; ...)
ah, the stored procedure argument.
Give me one reason why I can't do this from my BL tier?
- It provides a fool-proof way to ensure
there's only one version of the business logic in production :)
yeah, like that's an argument.. :)
Such safeguards in the database are simple to develop, and more
fool-proof than safeguards at another level. I think it's safe to
say enforcing BL in the database is a "best practice".

#define best.

You only argue that there is more than one way to do certain things,
to enforce certain behavior. You also forget things like:
you have a SAP system and a system in SQLServer. You want to run a
transaction with both SAP calls and SQLServer DML actions, as some data
is in SAP and other data is in the Sqlserver. It's logical to run such
a transaction using a transaction monitor like COM+ or tuxedo. From
inside the RDBMS? Not logical

SOME rules can be enforced at the RDBMS level, others are not. Some
are better of inside the RDBMS (referential integrity, null checks
etc., eventually using views to enforce data availability in
streamlined fashions). However the scope of BL is far broader than a
set of static integrity rules defined on the data. If I define a rule
"Customer C is a gold customer if customer C has purchased at least n
orders in the last m months and once becoming one, will stay a gold
customer for one year", I can enforce that in real time, in each select
for a customer, I can write a function in the RDBMS which is used for
that, I can also set a flag in the customer entity calculated on a
regular basis (e.g. when a customer purchases an order). Which is
better? Don't know, depends on the requirements. Though the outcome of
that results in where the code is placed. I don't need to place my flag
setter code inside an RDBMS, I can, but I don't have to. After all, the
code which makes the calls to the RDBMS to add an order isn't
originating from inside teh RDBMS also, is it?

What you suggest is typically a big-iron box in the basement, and
thin clients connecting to it, where all the software is written by
DBA's.
I hope I don't have to drop the word 'scalability' on you.

Would you agree with the statement that in the vast majority of
projects, scalability is not an issue?

You mean, they purchases such a big box for their rdbms it can run
forever without having to worry about scalability? I'm not sure, I
don't have statistical data for that, all I know is what I hear which
is that to be able to keep a big iron box running for a long time with
an RDBMS on it, it can be you run out of breathing room for the RDBMS
and placing new boxes in a BL farm is easier and cheaper than replacing
a big iron box with a bigger iron box.

FB
--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

Nov 17 '05 #35

On Tue, 26 Jul 2005 01:24:33 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

No law, but it is a well stablished principle in the database
community. You might check the first chapter of any popular
introductory book like Date, Elmasri & Navathe, Korth & Silverschatz,
etc.
I think you confuse some things. First of all, a lot of books about
database theory are rather old, say, the 80-ies.

Almost all have revision from the 00-ies.
In that time, having
distributed applications was a non-existing phenomenon.
Very wrong. Distributed applications are even older. Almost all
database books have chapters devoted to distributed DBMS. In fact
client/server is also a special case (the simplest) of distributed
system.
Of course the
rules were described to be inside the RDBMS, as the RDBMS was located
on the mainframe / mini.
Wrong again. A distributed DBMS might have parts located in the PCs,
and you can build a network of federated DBMS's having DBMS's
installed on the client PCs.
However times changed. In a distributed environment, business rules
aren't necessarily placed inside the RDBMS, as there's no real need to
do that.
All the reasons mentioned by the books still apply. It is still
foolish to implement the business rules in the applications.
I haven't heard any argument in favor of doing so from you yet.
They are in the elementary texts.

http://ioc.unesco.org/oceanteacher/r...dvantages.html
http://db.cs.berkeley.edu/postmodern...mer/sld011.htm

The most important argument in my opinion is that the development and
maintenance costs are reduced to a little fraction. A few lines of SQL
might be equivalent to many dozens of C# pages. C# is still a 3GL, and
SQL is an orders of magnitude more productive 4GL.

Oh, and the 'database community' is largely formed by DBA's. Of course
they don't want to give up their role as BL developer as it would
degrade their position in the company/organisation.
We could say the same about application programmers and the
consquences are evil. They break a very fundamental principle and
waste lots of resources in order to have a better position in the
company/organization.

If fact, to maximize the development and maintenance costs and to
create a big mess in which nobody else is able to find anything tends
to be very good for the programmers. The system often rewards
incompetence.
Oh dear, I don't have a clue,
Absolutely!

Fortunately it has an easy solution.

I recomend this book to you:

http://www.amazon.com/exec/obidos/tg...88825?v=glance

It was published in 2003.

I also strongly recomend this complementary website:

www.dbdebunk.com
Business rules aren't the same as integrity rules.
What are they then?

I readed several books about business rules and all of then say the
same.

http://www.amazon.com/exec/obidos/tg...08507?v=glance
http://www.amazon.com/exec/obidos/tg...704546-5588825
http://www.amazon.com/exec/obidos/AS...704546-5588825

It is evident again that you don't have a clue on what you talk.
If you would come
off your high horse, you'd learn I do agree with placing data-integrity
rules inside the database. Though it's something else to place behavior
in the database as well. After all, a relational model defines static
rules, but not behavior.
You are regurgiting nonsenses you readed somewhere without thinking.

It does not make any sense. DBMSs are computationally complete, you
might program any behavior you want with them, and thanks to the very
high level nature of the relational languages, it would take orders of
magnitude less effort than to use a comparatively low level procedural
language like C#.

Try to duplicate the behavior of a view that joins three tables and
has a multi-attribute "group by" clause using C#.
in 1981, the only computing model available was the mainframe/mini
setup: large box in the corner/basement, and terminals. There was no
other solution than that. No n-tier development, just a single tier,
located on the server.
Definitely you don't have a clue!

Any rookie knows that an Information System that uses a DBMS to
decouple the applications from the database has more than one tier.

The Relational Model is nothing but a direct application of set theory
and predicate logic to the data management field. If you don't know
that then you know practically nothing about it.

Dear Alfredo Novoa, why do you even take the time to lecture me about
relational model theory?

Because you are spreading a lot of misinformation that might harm many
readers.
Because you want to show the world you're the
only person who knows it all?
Any competent developer knows all or almost all what I said.

the relational model doesn't define predicate logic
No, I said that it is directly based in predicate logic.
the relational model offers you the structure but not the behavior.
I already showed to you that the structural component is only one of
the three components of any database model.

This is like to talk with a wall.

My proposed "setup" might have infinite architectural forms. Client
Server is only an special kind of distributed system. A distributed
DBMS composed by zillions of servers still is a single DBMS.

No, your only possible setup is: everything in the RDBMS and on top of
that a thin client with solely presentation functionality. Any business
rule is in teh RDBMS after all.

Presentation functionality might be very complex and important. In
many cases presentation functionality is the biggest part of the work
by far. You should not fear the proper use of a DBMS so much.
aha, all business logic is written by DBA's, there we have the
background of your story. Check out the 'A' in DBA. It doesn't stand
for progrAmmer.
Administration is more than programming. Programming is only one of
the skills a DBA must have.
Writing procedural code in SQL is stupid also.
What is stupid is to write procedural code when it is possible to use
declarative code, which is orders of magnitude more productive.
BL code is procedural by nature, not set-oriented.

The biggest nonsense you said until now.

Business rules are declarative by nature.

See this:

Best practices
Declarative: A business rule is a statement of truth about an
organization. It is an attempt to describe the operations of an
organization, not an attempt to prescribe how an organization should
operate. This is why business rules are said to be discovered or
observed and not created.

http://en.wikipedia.org/wiki/Business_rules

Scalability has nothing to do with this. There are many ways to scale
a well designed Information System where all the business logic is
ensured by the DBMS.

If you have an E10000 with your large oracle db on it, and because you
store all your logic inside that oracle instance as well, the server
needs expanding, you have more trouble than when your middle tier with
your BL needs expanding, as you then just place a tiny new server into
your BL sever farm and everything is OK.

You might have all your business logic on the DBMS and to have all the
physical tiers and distributed servers you want. Again you don't have
a clue on what you talk about.

There are many solutions: message servers, federated DBMSs, relational
middlewares, one server per database, etc, etc.

You have a LOT to learn
Regards

Nov 17 '05 #36

On Tue, 26 Jul 2005 01:38:50 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

Well, the only think you're achieving is that you look like some
60-year old gnu-emacs lover who comes in to tell us that VS.NET with
intellisense is the root of all evil.
VS.NET with intellisense is cool, I use it everyday.

What is not cool is to return to the dark ages of the data managed
directly by the applications transversing pointer labyrinths (the
50's).
What's also stunning is your serious lack of listening / reading
capabilities and the talent to realize we all have been to uni/college
to some degree and have studied the same dreaded books you have studied
and perhaps even way more than you have done.
I am pretty sure about I read a lot more and a lot better materials
than you. I returned from where you are a long time ago. I am aware of
the OO trade media, and the level is very poor.
What I find intriguing is that you didn't mention Yourdon in any way
in your lecturing comments.
His works are not very relevant to this thread.
I also have failed to see even ONE argument why ALL (not some, but
ALL) business rules and LOGIC (!) has to be written in code which is
placed INSIDE the RDBMS.
Indeed, you failed at many things. You only have to check any
introductory textbook. I already have recomended a very good one to
you.
... and data is only data. Information is something else.
OO is just a way to write software, or better: to look at how to
divide responsibility over what to write to increase re-usability and
structure.
OO re-usability has nothing to do compared to the possibility to reuse
a whole DBMS.

One of the questions was how we should put OO stuff into SQL. His
answer was that Bells Labs, with all their talent, had tried four
different approaches to this problem and come the conclusion that you
should not do it. OO was great for programming but deadly for data.
--------

OO == data+behavior.

behavior == integrity + derivation

I am developing a new generation RDBMS using C#

a new 'generation' RDBMS? Ah no wonder you want everything INSIDE the
rdbms!.

Well, it would be cool to have declarative presentation rules in the
database, but it is not about that.
But what's a new generation? Post-relational database system
like uniVerse, with 3D tables? Or plain old boring RDBMS like we all
know so not really 'new generation' ?
Truly Relational DBMS. TRDBMS. A DBMS without the problems of the SQL
DBMS.

Post-Relational does not exist and uniVerse is very primitive.

BTW C# and VS are also interesting for building presentation
applications that use a DBMS properly, although ADO.NET has very
serious flaws.

http://grumpyoldprogrammer.myblogsit...7/1004708.html
Not everyone has the same opinion as you do, nor are you the only
one who knows it all.

But some people have the same opinion as me, and casually they are the
best database experts with hundreds of thousands of books sold. They
are the ones that count.
Regards

Nov 17 '05 #37

Hi,

Looks like you are approaching the design question from a designers
perspective. I was looking more from the experienced developer
viewpoint. All systems with application-level BL enforcement have
inconsistent data. (Not by Law, or theory, but in my experience.)

It's not as if the data inside the database isn't storable anymore if
I don't place a check-constraint on a table or add a trigger somewhere.
Also it doesn't have to conflict with my relational model.
Yes, of course.

In practice tho, it is hard to enfore contraints beyond the database.
When the system is setup, the designer (like yourself) can enfore business
rules in, for example, COM+ objects.

But next year, a consultant is brought in to couple the system to another
system. If your documentation is good, he'll know he should modify the
COM+ objects. However, his employer expects him to finish in two weeks,
the system administrator doesn't want to install or change the
COM+ objects for this project, and his bulk migration script doesn't
perform well in COM+ anyway. So, he connects directly to the database.

And, that's the end of the process logic enforcement.

- It can restrict status transitions by controlling the
change through a stored procedure (like moving an order from
InProgress to Fullfilled; requiring a resolve-date when a help desk
ticket is closed; ...)

ah, the stored procedure argument.
Give me one reason why I can't do this from my BL tier?

No fool-proof reasons, but here are a couple of arguments:
- Someone else can connect to the database and make changes without
calling the BL tier.
- Its easier to make BL breaking mistakes in the application tier.
- The application tier may contain out-of-date information.

- It provides a fool-proof way to ensure
there's only one version of the business logic in production :)

yeah, like that's an argument.. :)

Why not? It's an advantage right?

Such safeguards in the database are simple to develop, and more
fool-proof than safeguards at another level. I think it's safe to
say enforcing BL in the database is a "best practice".

#define best.

Define #define best?

Seriously... a "best practice" has been shown to work and make a
significant difference in a majority of cases. See "Rapid Development" by
Steve McConnel. There is more than one best practice, of course.
You only argue that there is more than one way to do certain things,
to enorce certain behavior. You also forget things like:
you have a SAP system and a system in SQLServer. You want to run a
transaction with both SAP calls and SQLServer DML actions, as some data
is in SAP and other data is in the Sqlserver. It's logical to run such
a transaction using a transaction monitor like COM+ or tuxedo. From
inside the RDBMS? Not logical
I agree that calling SAP from within the RDBMS isn't logical; but what
does that have to do with BL enforcement? Enforcing BL is done within an
application, not between applications.

By the way, SAP has excellent BL enforcement, and most of it in its
application layer. :) But SAP is special.
You mean, they purchases such a big box for their rdbms it can run
forever without having to worry about scalability? I'm not sure, I
don't have statistical data for that, all I know is what I hear which
is that to be able to keep a big iron box running for a long time with
an RDBMS on it, it can be you run out of breathing room for the RDBMS
and placing new boxes in a BL farm is easier and cheaper than replacing
a big iron box with a bigger iron box.

Actually I mean most projects are so small-scale that performance is not
an issue. Only the largest of projects have a BL farm, I would hope! :)

Greetings,
Wessel

Nov 17 '05 #38

On Tue, 26 Jul 2005 13:37:01 +0200, "Wessel Troost"
<no*****@like.the.sun> wrote:

By the way, SAP has excellent BL enforcement, and most of it in its
application layer. :) But SAP is special.

SAP is a botch-up.
Regards

Nov 17 '05 #39

Andre Botelho

Hi... we have a battle here! Well I am new to this development stuff (five ou
six years only) and I just want to give my humble opinion here.

I agree with Alfredo in alot of things, but I also think we should keep our
minds open to new ideas. I think there is no design solution that can be
called "the best solution for all your problens". The best solution is the
one you plan before building applications, it depends on the team experience,
it depends on the tools you can use, on the business details, enabled
hardware... so it is hard to discuss about the best development practice
sometimes you just have to do the thing even if you do not agree with the
design.

Well... please do not turn your wrath on me... it is just an opinion... I do
not have half the knowlege all of you around has... but one think I must say
THANKS A LOT I learned a lot with this post!!!

Sorry for my poor english... I am brazilian...

"Alfredo Novoa" wrote:

On Tue, 26 Jul 2005 01:24:33 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:
No law, but it is a well stablished principle in the database
community. You might check the first chapter of any popular
introductory book like Date, Elmasri & Navathe, Korth & Silverschatz,
etc.

I think you confuse some things. First of all, a lot of books about
database theory are rather old, say, the 80-ies.

Almost all have revision from the 00-ies.
In that time, having
distributed applications was a non-existing phenomenon.

Very wrong. Distributed applications are even older. Almost all
database books have chapters devoted to distributed DBMS. In fact
client/server is also a special case (the simplest) of distributed
system.
Of course the
rules were described to be inside the RDBMS, as the RDBMS was located
on the mainframe / mini.

Wrong again. A distributed DBMS might have parts located in the PCs,
and you can build a network of federated DBMS's having DBMS's
installed on the client PCs.
However times changed. In a distributed environment, business rules
aren't necessarily placed inside the RDBMS, as there's no real need to
do that.

All the reasons mentioned by the books still apply. It is still
foolish to implement the business rules in the applications.
I haven't heard any argument in favor of doing so from you yet.

They are in the elementary texts.

http://ioc.unesco.org/oceanteacher/r...dvantages.html
http://db.cs.berkeley.edu/postmodern...mer/sld011.htm

The most important argument in my opinion is that the development and
maintenance costs are reduced to a little fraction. A few lines of SQL
might be equivalent to many dozens of C# pages. C# is still a 3GL, and
SQL is an orders of magnitude more productive 4GL.

Oh, and the 'database community' is largely formed by DBA's. Of course
they don't want to give up their role as BL developer as it would
degrade their position in the company/organisation.

We could say the same about application programmers and the
consquences are evil. They break a very fundamental principle and
waste lots of resources in order to have a better position in the
company/organization.

If fact, to maximize the development and maintenance costs and to
create a big mess in which nobody else is able to find anything tends
to be very good for the programmers. The system often rewards
incompetence.
Oh dear, I don't have a clue,

Absolutely!

Fortunately it has an easy solution.

I recomend this book to you:

http://www.amazon.com/exec/obidos/tg...88825?v=glance

It was published in 2003.

I also strongly recomend this complementary website:

www.dbdebunk.com
Business rules aren't the same as integrity rules.

What are they then?

I readed several books about business rules and all of then say the
same.

http://www.amazon.com/exec/obidos/tg...08507?v=glance
http://www.amazon.com/exec/obidos/tg...704546-5588825
http://www.amazon.com/exec/obidos/AS...704546-5588825

It is evident again that you don't have a clue on what you talk.
If you would come
off your high horse, you'd learn I do agree with placing data-integrity
rules inside the database. Though it's something else to place behavior
in the database as well. After all, a relational model defines static
rules, but not behavior.

You are regurgiting nonsenses you readed somewhere without thinking.

It does not make any sense. DBMSs are computationally complete, you
might program any behavior you want with them, and thanks to the very
high level nature of the relational languages, it would take orders of
magnitude less effort than to use a comparatively low level procedural
language like C#.

Try to duplicate the behavior of a view that joins three tables and
has a multi-attribute "group by" clause using C#.
in 1981, the only computing model available was the mainframe/mini
setup: large box in the corner/basement, and terminals. There was no
other solution than that. No n-tier development, just a single tier,
located on the server.

Definitely you don't have a clue!

Any rookie knows that an Information System that uses a DBMS to
decouple the applications from the database has more than one tier.
The Relational Model is nothing but a direct application of set theory
and predicate logic to the data management field. If you don't know
that then you know practically nothing about it.

Dear Alfredo Novoa, why do you even take the time to lecture me about
relational model theory?

Because you are spreading a lot of misinformation that might harm many
readers.
Because you want to show the world you're the
only person who knows it all?

Any competent developer knows all or almost all what I said.

the relational model doesn't define predicate logic

No, I said that it is directly based in predicate logic.
the relational model offers you the structure but not the behavior.

I already showed to you that the structural component is only one of
the three components of any database model.

This is like to talk with a wall.
My proposed "setup" might have infinite architectural forms. Client
Server is only an special kind of distributed system. A distributed
DBMS composed by zillions of servers still is a single DBMS.

No, your only possible setup is: everything in the RDBMS and on top of
that a thin client with solely presentation functionality. Any business
rule is in teh RDBMS after all.

Presentation functionality might be very complex and important. In
many cases presentation functionality is the biggest part of the work
by far. You should not fear the proper use of a DBMS so much.
aha, all business logic is written by DBA's, there we have the
background of your story. Check out the 'A' in DBA. It doesn't stand
for progrAmmer.

Administration is more than programming. Programming is only one of
the skills a DBA must have.
Writing procedural code in SQL is stupid also.

What is stupid is to write procedural code when it is possible to use
declarative code, which is orders of magnitude more productive.
BL code is procedural by nature, not set-oriented.

The biggest nonsense you said until now.

Business rules are declarative by nature.

See this:

Best practices
Declarative: A business rule is a statement of truth about an
organization. It is an attempt to describe the operations of an
organization, not an attempt to prescribe how an organization should
operate. This is why business rules are said to be discovered or
observed and not created.

http://en.wikipedia.org/wiki/Business_rules
Scalability has nothing to do with this. There are many ways to scale
a well designed Information System where all the business logic is
ensured by the DBMS.

If you have an E10000 with your large oracle db on it, and because you
store all your logic inside that oracle instance as well, the server
needs expanding, you have more trouble than when your middle tier with
your BL needs expanding, as you then just place a tiny new server into
your BL sever farm and everything is OK.

You might have all your business logic on the DBMS and to have all the
physical tiers and distributed servers you want. Again you don't have
a clue on what you talk about.

There are many solutions: message servers, federated DBMSs, relational
middlewares, one server per database, etc, etc.

You have a LOT to learn
Regards

Nov 17 '05 #40