Data Layer architecture

[Alfredo Novoa]

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?

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

 

[Steve Walker]

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.

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 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.

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.

 

[Alfredo Novoa]

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.

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.

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.

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

 

[Steve Walker]

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.

 

[Alfredo Novoa]

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

 

[Frans Bouma [C# MVP]]

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).

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, 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.

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/detail/-/0201612941?v=glance


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.

System >> (something known since the 60's), and we should keep away
from all the >> business objects trade media garbage.

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.

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.

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


--

 

[Frans Bouma [C# MVP]]

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.

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.

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.


--

 

[Frans Bouma [C# MVP]]

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.

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?

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


--

 

[Alfredo Novoa]

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/resourcekit/Module2/Database/DBMS/advantages.html
http://db.cs.berkeley.edu/postmodern/lecs/dbprimer/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/detail/-/0321197844/002-4704546-5588825?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/detail/-/0201708507?v=glance
http://www.amazon.com/exec/obidos/tg/detail/-/0471412937/002-4704546-5588825
http://www.amazon.com/exec/obidos/ASIN/0201788934/002-4704546-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.

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.

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

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

 

[Alfredo Novoa]

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.

OO == data+behavior.

behavior == integrity + derivation

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.myblogsite.com/blog/_archives/2005/7/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

 

[Wessel Troost]

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.

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.

yeah, like that's an argument..

Why not? It's an advantage right?

#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

 

[Alfredo Novoa]

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

 

[Guest]

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]

On Tue, 26 Jul 2005 06:55:02 -0700, "Andre Botelho" <Andre

I agree with Alfredo in alot of things, but I also think we should keep our
minds open to new ideas.

The problem is that truly new ideas are rare. Most supossed new ideas
were tried and discarded many years ago. Those who don't know the past
are doomed to repeat it.

See this:

http://c2.com/cgi-bin/wiki?ModernDinosaur

And also this:

http://www.drma-seattle.org/dbpicture_1.htm

I think there is no design solution that can be
called "the best solution for all your problens".

Indeed, but many solutions are never the best solution to any problem,
and this is the case of the business objects stuff. A reinvention of
the worst practices of the 50's.


Regards

 

[Guest]

The problem is that truly new ideas are rare. Most supossed new ideas

were tried and discarded many years ago. Those who don't know the past
are doomed to repeat it.

I agree. I would risk to say that Java, and .NET (though .NET is how could
I say a better Java), are the best ideas in recent times.

See this:

http://c2.com/cgi-bin/wiki?ModernDinosaur

And also this:

http://www.drma-seattle.org/dbpicture_1.htm

The first link is very cool! ModernDinosaur is a very interesting
concept. I must tell that I do not agree with all the ideas in the link, but
I could learn something about the past and thats nice to me. I agree that
OODB are something weird for me right now, I have always worked with
relational data bases and never saw a OODB that really worked, nor did I ever
heard about a project that used a OODB. And now that I know it has existed in
the past in the form of hierarquical db...
The second link I did not read yet... but I will I promise!

Indeed, but many solutions are never the best solution to any problem,
and this is the case of the business objects stuff. A reinvention of
the worst practices of the 50's.

Well I still do not agree, I have worked with the business stuff, and it
did a good job in the project, I believe the problem is when you think that
the business stuff is the great solution and put all your faith and code on
it. Moderation is the word I believe, I like the two aproachs, the rules in
DB and the rules in business objects, both work, it is up to the project
requirements.
For example... your enterprise has a software product for commercial
purposes, one client wants it in SQL Server, the other in Oracle... if you
have a good model you will only have to alter your persistence to some litle
differences in the sql sintaxe. But if all the rules are in the DB, you must
rewrite most of your code, and run the scripts in the other DB... and tests
will be necessary in both cases, but I think the business stuff work better
here. And I believe coding in a programming language is much clearer then in
SQL.
Another detail, if all the rules are in database, then he must be able to
support all the calls, when it is in the code, it is processed in the client
in memory. But when you have to change a rule, you can edit a stored
procedure and all clients will be updated automatically no need for compiling
and deployment again...
I hope I am not speaking too much stupid things... please enlight myself
if so...


my best regards...