Datasets vs. OOP

[cody]

I've seen an Introduction on ADO.NET with its Datasets on .NET TV and Iam
now wondering how it is realized/used in real world applications.

I don't believe that one would create a dataset and add relations to it and
so on for every table in the application, this would be a real mess and this
has nothing to do with OOP.

Normally, would would create a class Customer, a class Invoices, Positions,
Articles and so on.
But how can this be realized using Datasets? Datasets and encapsulating data
+ hiding implemention in classes seems to be a contradiction to me.

Sorry for me stupidness but I found no example explaining this.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[Peter van der Goes]

"cody" <pl*************************@gmx.de> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...

I've seen an Introduction on ADO.NET with its Datasets on .NET TV and Iam
now wondering how it is realized/used in real world applications.

I don't believe that one would create a dataset and add relations to it and so on for every table in the application, this would be a real mess and this has nothing to do with OOP.

Normally, would would create a class Customer, a class Invoices, Positions, Articles and so on.
But how can this be realized using Datasets? Datasets and encapsulating data + hiding implemention in classes seems to be a contradiction to me.

Sorry for me stupidness but I found no example explaining this.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

Actually, as DataSet is a class in the ADO.NET hierarchy, it has everything
to do with OO.
You use one or more DataSet objects in your OO solution. How you choose to
have objects from your own class definitions interact with DataSet objects
is up to you.
For example, if create an instance of your Customer class, the datamembers
of your object could be set from a given row in a table within a DataSet
object, if it made sense to do so in your scenario.
By using DataSet objects, you're taking advantage of inheritance and
encapsulation, two of the more prominent features of OO.

Peter [MVP Visual Developer]
Jack of all trades, master of none.

[Alfredo]

On Mon, 10 May 2004 01:06:44 +0200, "cody"
<pl*************************@gmx.de> wrote:

I don't believe that one would create a dataset and add relations to it and
so on for every table in the application
Tables are not in the application, they are in the DBMS.
, this would be a real mess and this
has nothing to do with OOP.
Data management has nothing to do with OOP.
Normally, would would create a class Customer, a class Invoices, Positions,
Articles and so on.
But that is a blunder. Customers, Invoices, Articles, etc should be
tables not classes. Tables and classes are radically different.
But how can this be realized using Datasets? Datasets and encapsulating data
+ hiding implemention in classes seems to be a contradiction to me.

Datasets are not for that. They are for presenting the tables to the
users.
Regards
Alfredo

[Jay B. Harlow [MVP - Outlook]]

Cody,
Martin Fowler's book "Patterns of Enterprise Application Architecture" from
Addison Wesley discusses when to use "Data Sets" and when to create a Domain
Model. http://www.martinfowler.com/books.html#eaa

Using either Typed DataSets or untyped DataSets, is a viable Object Oriented
approached to creating solutions in .NET. In addition to the more
"traditional" Domain Objects (business objects) approach to. Martin uses the
term Table Module pattern to refer to using a DataSet.

Martin's book discusses when you should consider one over the other, plus
various patterns to support an OO approach with either (DataSet or Domain
object) approach.

For example I would consider a Table Module & Table Data Gateway approach if
my "Domain objects" did not have any real logic to them. See
http://www.martinfowler.com/eaaCatalog/tableModule.html &
http://www.martinfowler.com/eaaCatal...taGateway.html patterns

However if my "Domain Objects" had heavy logic to them, then I would use a
Domain Model and Data Mapper approach. See:
http://www.martinfowler.com/eaaCatalog/domainModel.html &
http://www.martinfowler.com/eaaCatalog/dataMapper.html patterns

Note: My Data Mappers would use a DataReader to read an row from the
database to create a new Domain object, passing the information for a row to
the constructor of the Domain object.

Hope this helps
Jay

"cody" <pl*************************@gmx.de> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...

I've seen an Introduction on ADO.NET with its Datasets on .NET TV and Iam
now wondering how it is realized/used in real world applications.

I don't believe that one would create a dataset and add relations to it and so on for every table in the application, this would be a real mess and this has nothing to do with OOP.

Normally, would would create a class Customer, a class Invoices, Positions, Articles and so on.
But how can this be realized using Datasets? Datasets and encapsulating data + hiding implemention in classes seems to be a contradiction to me.

Sorry for me stupidness but I found no example explaining this.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[William Ryan eMVP]

Hi Cody:
"cody" <pl*************************@gmx.de> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...

I've seen an Introduction on ADO.NET with its Datasets on .NET TV and Iam
now wondering how it is realized/used in real world applications.

I don't believe that one would create a dataset and add relations to it and so on for every table in the application, this would be a real mess and this has nothing to do with OOP.
I totally agree with the Mess part. It may or may not have something to do
with the OOP part. An object doesn't really care how it's properties get
set as long as the follow the accessor's rules.I konw that's not the point
you were making but that's why I say it may or may not have something to do
with OOP.

Datasets are composed of datatables and datatables are Two dimensional
objects. With DataRelations that can change quite a bit. However, there
are more than a few structures out there that don't fit very comfortably
into the Relational model.

There's a philosophy known as OR/M (Object Relational Mapping) that tends to
bridge this gap, and if you look at ADO.NET 2.0 ,there's an object called an
ObjectSpace that addresses your concerns. OR/M tools basically handle the
mapping of your object properties to you database schema (this is an
oversimplification but it doesn't change the point). Anyway, OR/M tools
sell b/c they do what is a real pain in the butt (see Messy) to do in many
instances.

But the problem is that any downside of DataSets inherent in Relational
Dataabases. I agree that it's not always clean and depending on your
requirements, you may end up shoving Square pegs down round holes but it's
the best we have.
Normally, would would create a class Customer, a class Invoices, Positions, Articles and so on.
But how can this be realized using Datasets? The devil is really in the details and the problem here is that you may have
many-to-many relationships which are a nightmare to handle with the current
model. The short answer is create four tables, link them where you can. I
can think of implementations I've worked on where this would fit right in
with the dataset model, and just as easiler think of ones that were ghastly.
It really depends on the implementation of each class, and I know that's
sounds more like an excuse than an answer, but IMHO, it's a situation where
you have to take the good with the bad.
Datasets and encapsulating data + hiding implemention in classes seems to be a contradiction to me.
It can certainly be but not necessarily so. Like I mentioned in the
beginning, it's not a contradiction in that the object doesn't care where
it's data comes from. A dataset whose structure can mimic the object
strucutre is a very natural fit. But I'm not going to pretend that there
aren't a bunch of situations where the implementation is awkward.

Regrettably, OOP isn't a perfect model either and not everything can be
modeled by objects (why do I get the feeling I'm opening a can of worms with
this last statement ;-) ). Rather, everything can probably be modelled,
but not elegantly. Same with DataSet.
Sorry for me stupidness but I found no example explaining this.
I think that the result is that you need to consider the tools you have at
your disposal. For years, Joins were really costly (and still are in many
situations) in most RDMBS situations in many circumstances, but that has
nothing to do with Relational theory. On the contrary. However, the
pragmatic reality made the theoritical application a 'contradiction'...
should I normalize to xNormal form or not? So many modelled tables to
performance issues over theoretical correctness even though the theory was
totally correct.

I suspect this is a similar albiet nonidentical situation. I know this is a
bit abstract of an answer but it's really hard to get more specific without
using specific instances. I'll gladly elaborate on specific examples and I
can be a lot more clear then.

Cheers,

Bill
www.devbuzz.com
www.knowdotnet.com

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[Cor Ligthert]

Hi Cody,

In addition to Bill Ryan,

I see this often on this dotNet newsgroups. It seems that OOP is only OOP
when you make your own collections using the object methods.

I think it is something more.

For the rest I think the most is said in this thread.

Just my thought.

Cor

[Frans Bouma [C# MVP]]

Peter van der Goes wrote:

"cody" <pl*************************@gmx.de> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...

I've seen an Introduction on ADO.NET with its Datasets on .NET TV and Iam
now wondering how it is realized/used in real world applications.

I don't believe that one would create a dataset and add relations to it and

so on for every table in the application, this would be a real mess and

this

has nothing to do with OOP.

Normally, would would create a class Customer, a class Invoices,

Positions,

Articles and so on.
But how can this be realized using Datasets? Datasets and encapsulating

data

+ hiding implemention in classes seems to be a contradiction to me.

Actually, as DataSet is a class in the ADO.NET hierarchy, it has everything
to do with OO.
You use one or more DataSet objects in your OO solution. How you choose to
have objects from your own class definitions interact with DataSet objects
is up to you.
I hate to spoil the party, Peter, but DataSets lack a lot in the OO area.
For example, the building blocks of datasets are deep down, the datarows and
the datacolumns. There is no public constructor for the datarow. The datarow
can only be created by a datatable. This is because the cells of a datarow
are described by column objects in the datatable. In other words, you can't
use datarow objects on their own, you need a datatable and datacolumns as
well.

You can subclass the datarow, for example to add a property, but this will
create a lot of mess: first you also have to subclass DataTable to produce
your own datarow classes. Now the fun part begins. The embedded functionality
inside the DataTable is not seeing your added code. For example when you bind
to the datatable, the embedded code will completely ignore your property and
it will not show up in the bound grid. Furthermore, serializing the Datatable
will completely skip the new property.

There is also no way you can extend this code, as the methods are made
private (ISerializable is implemented private).
For example, if create an instance of your Customer class, the datamembers
of your object could be set from a given row in a table within a DataSet
object, if it made sense to do so in your scenario.
By using DataSet objects, you're taking advantage of inheritance and
encapsulation, two of the more prominent features of OO.

I fail to see where you take advantage of inheritance when using a DataSet.
All important technology in the dataset is hidden and can't be extended. As a
matter of fact, you can't even create serialization code in the subclass you
derive from DataTable when you use VB.NET, as you can't implement
ISerializable on the derived class because DataTable implements it private
and VB.NET doesn't let you implement it again. You can in C#, by explicitly
implement the interface, however you can't call DataTAble's base class
serialization code, which means that you have to do the serialization
completely yourself.

A datatable is a container/bucket for arrays of object references (datarows)
and it contains per cell index position of these arrays 1 datacolumn object
to describe the contents of all the cells at that index in all the arrays. A
DataSet is a container/bucket for datatables and defines relations between
them via objects. DataSets and friends, although perhaps useful, are a very
bad example for OOP.

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Frans Bouma [C# MVP]]

William Ryan eMVP wrote:

"cody" <pl*************************@gmx.de> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...

I've seen an Introduction on ADO.NET with its Datasets on .NET TV and Iam
now wondering how it is realized/used in real world applications.

I don't believe that one would create a dataset and add relations to it and

so on for every table in the application, this would be a real mess and

this

has nothing to do with OOP. [...] There's a philosophy known as OR/M (Object Relational Mapping) that tends to
bridge this gap, and if you look at ADO.NET 2.0 ,there's an object called an
ObjectSpace that addresses your concerns.
No, that's been removed from ADO.NET. It will be released separately.
Normally, would would create a class Customer, a class Invoices,Positions,
Articles and so on. But how can this be realized using Datasets?

The devil is really in the details and the problem here is that you may have
many-to-many relationships which are a nightmare to handle with the current
model. The short answer is create four tables, link them where you can.

m:n relations are definitions of a higher abstract form, like you find in
NIAM/ORM. In the relational model, they do not exist, in there you only have
FK constraints. You can semantically define relations between elements,
however you always require 1 or more elements:
1:1 relation can be: a PK - PK relation or a PK - FK(non PK)/UC relation
a m:n relation is always build with: a 1:n and a m:1 relation. Because you
can define an m:n relation and an 1:1 relation with different elements, you
can also simply specify these elements and use them separately. For 1:1
relations this can be a real pain, and it's not hard to specify 1:1 relations
with the same logic as 1:n relations are specified because they too are
defined between 2 elements (attribute sets, living in separate tables or in
teh same table).

m:n relations are different because they require an intermediate element
where both ends of the m:n relation are related with. (order <- orderlines ->
product) The problem begins when you want to save 2 elements which are
related via an m:n relation. What to do with the intermediate element? Create
automatically or do you have to add this as well? I find it KEY that that
intermediate element is visible and has to be saved as well. Because if
that's the case, the whole relational model inside a dataset or object model
is much simpler to understand and to work with and code stays consistent.
Datasets and encapsulating data

+ hiding implemention in classes seems to be a contradiction to me.

It can certainly be but not necessarily so. Like I mentioned in the
beginning, it's not a contradiction in that the object doesn't care where
it's data comes from. A dataset whose structure can mimic the object
strucutre is a very natural fit. But I'm not going to pretend that there
aren't a bunch of situations where the implementation is awkward.

Regrettably, OOP isn't a perfect model either and not everything can be
modeled by objects (why do I get the feeling I'm opening a can of worms with
this last statement ;-) ). Rather, everything can probably be modelled,
but not elegantly. Same with DataSet.

:D

I'm with you here. DataSet objects are good at what they are for: being a
container for other containers in which data is stored which is related
(inside the table ! and between tables) based on information stored inside
the container at runtime. This is very flexible, but doesn't work in OOP very
well, where you have fixed definitions and you extend these through
inheritance and polymorphism.

Sorry for me stupidness but I found no example explaining this.

I think that the result is that you need to consider the tools you have at
your disposal. For years, Joins were really costly (and still are in many
situations) in most RDMBS situations in many circumstances, but that has
nothing to do with Relational theory.

Joins are very cheap btw, as they can be very well optimized. Subqueries on
the other hand ARE still very expensive.

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Cor Ligthert]

Hallo Frans,

A lot of text, however when I read this I have to think on the management
class, for which is much the same in my idea as you write.

When it is about dataset everybody seems to want to serialize to get an in
my idea older concept of dataprocessing.

My idea about it is that people want to keep the three tier, while I do not
see much necessary anymore for it (or better to say, it conflicts for me in
some cases)

However I place this to discuss, not because I am completly sure of it.

Before you understand it wrong, I have made applications in far past with
much more than three tiers, because I than seperated the datacom, the
database, the application, the security in seperated tiers.

So go ahead, shoot.

Cor

[Alfredo]

On Sun, 9 May 2004 22:39:08 -0400, "William Ryan eMVP"
<do********@comcast.nospam.net> wrote:

Regrettably, OOP isn't a perfect model either and not everything can be
modeled by objects
OOP is not a data management model. The known data management models
are The Network Model (with its specialization: The Hierarchical
Model) and The Relational Model.

Unfortunately many OO practicioners use the obsolete Network Model.
On the contrary. However, the
pragmatic reality made the theoritical application a 'contradiction'...
should I normalize to xNormal form or not? So many modelled tables to
performance issues over theoretical correctness even though the theory was
totally correct.

The dilemma is due to the lack of data independence of the current
DBMS products.
Regards
Alfredo

[Alfredo]

On Mon, 10 May 2004 02:05:31 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

bridge this gap, and if you look at ADO.NET 2.0 ,there's an object called an
ObjectSpace that addresses your concerns.
No, that's been removed from ADO.NET. It will be released separately.

Does anyone know why?

Because MS wants to make money with it or because it is too
controversial?
I'm with you here. DataSet objects are good at what they are for: being a
container for other containers in which data is stored which is related
(inside the table ! and between tables) based on information stored inside
the container at runtime.
DataSet objects are intended to map an SQL database.
Joins are very cheap btw, as they can be very well optimized. Subqueries on
the other hand ARE still very expensive.

Subqueries can be as well optimized as joins.
Regards
Alfredo

[Frans Bouma [C# MVP]]

Cor Ligthert wrote:

When it is about dataset everybody seems to want to serialize to get an in
my idea older concept of dataprocessing.
Not necessarily. Serializing a dataset is performed for example when you
return it from a webservice (XmlSerializer) or when you return it from a
remoted method (Soap/Binary formatter or your own).
My idea about it is that people want to keep the three tier, while I do not
see much necessary anymore for it (or better to say, it conflicts for me in
some cases)

n-tier programming is about semantics. You can create a single assembly and
still have a 3-tier application, as long as you keep logical groups separated.

FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Cor Ligthert]

Hi Frans,

I forgot to tell, serializing a dataset and deserialization is a piece of
cake when you use the stringreader and writer (which is not used in the
documentation as far as I know). This is all.

Serialize
\\\
Dim sw As New System.IO.StringWriter
ds.WriteXml(sw)
Dim mystring As String = sw.tostring
///
Deserialize
\\\
Dim sr As New System.IO.StringReader(mystring)
Dim ds2 As New DataSet
ds2.ReadXml(sr)
///

Cor

[Frans Bouma [C# MVP]]

Alfredo wrote:

On Mon, 10 May 2004 02:05:31 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

bridge this gap, and if you look at ADO.NET 2.0 ,there's an object called an >> ObjectSpace that addresses your concerns.

No, that's been removed from ADO.NET. It will be released separately.

Does anyone know why?
Because MS wants to make money with it or because it is too
controversial?

It will be free, but I think they removed it for a couple of reasons:
1) integration of a sqlserver only tool inside the .NET framework is perhaps
not a wise thing to do, competition wise. (Oracle f.e. couldn't write its own
SQL engine / mapping engine for objectspaces)
2) it is used in Microsoft Business Framework (and longhorn's winfs), which
are both not part of the .net framework so by releasing it separately, you
can focus on aspects required for those two techniques and not necessarily
have to build in stuff you don't need.

Again, my own opinion, no-one knows for sure.
I'm with you here. DataSet objects are good at what they are for: being a
container for other containers in which data is stored which is related
(inside the table ! and between tables) based on information stored inside
the container at runtime.

DataSet objects are intended to map an SQL database.

Where did you get this information? Afaik, they are intented to store
resultsets.

Joins are very cheap btw, as they can be very well optimized. Subqueries
on the other hand ARE still very expensive.

Subqueries can be as well optimized as joins.

No, because you have to perform different data-algebra expressions with
subqueries than with joins. Check the execution plans on northwind for:

SELECT DISTINCT Customers.* FROM
Customers INNER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
INNER JOIN Employees
ON Orders.EmployeeID = Employees.EmployeeID
Where Employees.Country = 'UK'

and:
SELECT *
FROM Customers
WHERE CustomerID IN
(
SELECT CustomerID
FROM Orders
WHERE EmployeeID IN
(
SELECT EmployeeID
FROM Employees
WHERE Country='UK'
)
)

Trace says: query 1 has a duration of 15 and 162 reads. QUery 2 has a
duration of 16 and 194 reads. It is hard to optimize outer query performance
based on a resultset from an inner query performance, because these
statistics are not known at compile time of the query (the join statistics
are, these are kept with the table, how many rows there are f.e.). So the
optimizer can easily optimize a join path by first trying to weed out as much
rows as possible by starting with the join with an operand the fewest rows. :)

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Peter van der Goes]

"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> wrote in message
news:xn***************@msnews.microsoft.com...

I hate to spoil the party, Peter, but DataSets lack a lot in the OO area.

<snip>
You didn't "spoil the party".
I detected what I believed to be a question from someone who has some basic
misunderstandings about OO, and I was answering in that vein.

[Alfredo]

On Mon, 10 May 2004 04:40:02 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

Again, my own opinion, no-one knows for sure.
Very informative, thanks.

DataSet objects are intended to map an SQL database.

Where did you get this information? Afaik, they are intented to store
resultsets.

The resultsets returned from an SQL database, to manage them and to
submit the changes to the DBMS. The same as I said but with other
words.

I know they can be used with non SQL based data, but it is clear that
it is the main intention.

Subqueries can be as well optimized as joins.

No, because you have to perform different data-algebra expressions with
subqueries than with joins. Check the execution plans on northwind for:

I said that they can be as well optimized as joins, not that SQL
Server optimize them as well as joins ;-)
Trace says: query 1 has a duration of 15 and 162 reads. QUery 2 has a
duration of 16 and 194 reads.

Query 2 could be transformed in Query 1 by the optimizer.
Regards
Alfredo

[William Ryan eMVP]

"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> wrote in message
news:xn***************@msnews.microsoft.com...

William Ryan eMVP wrote:

"cody" <pl*************************@gmx.de> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...

I've seen an Introduction on ADO.NET with its Datasets on .NET TV and Iam now wondering how it is realized/used in real world applications.

I don't believe that one would create a dataset and add relations to it

and

so on for every table in the application, this would be a real mess

and

this

has nothing to do with OOP. [...]

There's a philosophy known as OR/M (Object Relational Mapping) that

tends to bridge this gap, and if you look at ADO.NET 2.0 ,there's an object called an ObjectSpace that addresses your concerns.

No, that's been removed from ADO.NET. It will be released separately.

Nice to know, but I had quite a bit of info to the contrary, guess I need
to keep more up to date on it.
Normally, would would create a class Customer, a class

Invoices,Positions, Articles and so on. But how can this be realized using Datasets? The devil is really in the details and the problem here is that you may have many-to-many relationships which are a nightmare to handle with the current model. The short answer is create four tables, link them where you can.

m:n relations are definitions of a higher abstract form, like you find in
NIAM/ORM. In the relational model, they do not exist, in there you only

have FK constraints. You can semantically define relations between elements,
however you always require 1 or more elements:
1:1 relation can be: a PK - PK relation or a PK - FK(non PK)/UC relation
a m:n relation is always build with: a 1:n and a m:1 relation. Because you
can define an m:n relation and an 1:1 relation with different elements, you can also simply specify these elements and use them separately. For 1:1
relations this can be a real pain, and it's not hard to specify 1:1 relations with the same logic as 1:n relations are specified because they too are
defined between 2 elements (attribute sets, living in separate tables or in teh same table).

m:n relations are different because they require an intermediate element
where both ends of the m:n relation are related with. (order <- orderlines -> product) The problem begins when you want to save 2 elements which are
related via an m:n relation. What to do with the intermediate element? Create automatically or do you have to add this as well? I find it KEY that that
intermediate element is visible and has to be saved as well. Because if
that's the case, the whole relational model inside a dataset or object model is much simpler to understand and to work with and code stays consistent.

Datasets and encapsulating data

+ hiding implemention in classes seems to be a contradiction to me.
It can certainly be but not necessarily so. Like I mentioned in the
beginning, it's not a contradiction in that the object doesn't care where it's data comes from. A dataset whose structure can mimic the object
strucutre is a very natural fit. But I'm not going to pretend that there aren't a bunch of situations where the implementation is awkward.

Regrettably, OOP isn't a perfect model either and not everything can be
modeled by objects (why do I get the feeling I'm opening a can of worms with this last statement ;-) ). Rather, everything can probably be modelled, but not elegantly. Same with DataSet.

:D

I'm with you here. DataSet objects are good at what they are for: being a
container for other containers in which data is stored which is related
(inside the table ! and between tables) based on information stored inside
the container at runtime. This is very flexible, but doesn't work in OOP

very well, where you have fixed definitions and you extend these through
inheritance and polymorphism.
Sorry for me stupidness but I found no example explaining this.
I think that the result is that you need to consider the tools you have at your disposal. For years, Joins were really costly (and still are in many situations) in most RDMBS situations in many circumstances, but that has
nothing to do with Relational theory.

Joins are very cheap btw, as they can be very well optimized. Subqueries

on the other hand ARE still very expensive.
They can be cheap if done correctly, they can also be 'expensive' although
that's still a relative term. The point is that the implementation of a
model doesn't mean the model is weak. For years while i was too small to
read and before I was born, there was a fair amount of literature and
stereotypes that the relational model was mud just b/c the vendor
implementation didn't do X well for instance. Since I was sucking my thumb
at the time instead of using Oracle 1.0.1, I have to just look to what was
written and many themes and misconceptions seemed to be fairly commonplace.
But this didn't have anything to do with the model's failure and that was
ostensibly the analogy I was trying to make
FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Alfredo]

On Mon, 10 May 2004 04:25:25 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

n-tier programming is about semantics.

N-tier programming is about physical tiers. You still have a logical
client and a logical server.
Regards
Alfredo

[William Ryan eMVP]

"Alfredo" <al*****@nospam.es> wrote in message
news:40**************@msnews.microsoft.com...

On Sun, 9 May 2004 22:39:08 -0400, "William Ryan eMVP"
<do********@comcast.nospam.net> wrote:

Regrettably, OOP isn't a perfect model either and not everything can be
modeled by objects
OOP is not a data management model. The known data management models
are The Network Model (with its specialization: The Hierarchical
Model) and The Relational Model.

Ok, cool. I don't think I was making that point at all, so sorry if it
somehow sounded like I was.

Unfortunately many OO practicioners use the obsolete Network Model. There are a lot of toerh misaaplications of OOP that are far more complex
than just this issue.

On the contrary. However, the
pragmatic reality made the theoritical application a 'contradiction'...
should I normalize to xNormal form or not? So many modelled tables to
performance issues over theoretical correctness even though the theory wastotally correct.
The dilemma is due to the lack of data independence of the current
DBMS products.

I'm not sure I understand what you mean here, but if your point is that
tightly coupling Data with the objects they represent is a problem, then yes
I agree.

Regards
Alfredo

[Frans Bouma [C# MVP]]

Cor Ligthert wrote:

I forgot to tell, serializing a dataset and deserialization is a piece of
cake when you use the stringreader and writer (which is not used in the
documentation as far as I know). This is all.

Serialize
\\\
Dim sw As New System.IO.StringWriter
ds.WriteXml(sw)
Dim mystring As String = sw.tostring
///
Deserialize
\\\
Dim sr As New System.IO.StringReader(mystring)
Dim ds2 As New DataSet
ds2.ReadXml(sr)
///

I know, but when you subclass the DataTable class and add a property, it
will not be serialized into the data.

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Frans Bouma [C# MVP]]

Alfredo wrote:

On Mon, 10 May 2004 04:25:25 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

n-tier programming is about semantics.

N-tier programming is about physical tiers. You still have a logical
client and a logical server.

There is no n-tier 'law', so saying it is about physical tiers is IMHO your
interpretation, not 'the' interpretation, because there is none.

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Alfredo]

On Mon, 10 May 2004 08:14:46 -0400, "William Ryan eMVP"
<do********@comcast.nospam.net> wrote:

Unfortunately many OO practicioners use the obsolete Network Model.

There are a lot of toerh misaaplications of OOP that are far more complex
than just this issue.

But this is an important issue IMO. For instance O/R mappers are tools
intended to apply the Network approach misusing the DBMSs as mere
storage mechanisms.

>On the contrary. However, the
>pragmatic reality made the theoritical application a 'contradiction'...
>should I normalize to xNormal form or not? So many modelled tables to
>performance issues over theoretical correctness even though the theorywas >totally correct.

The dilemma is due to the lack of data independence of the current
DBMS products.

I'm not sure I understand what you mean here, but if your point is that
tightly coupling Data with the objects they represent is a problem, then yes
I agree.

No, I mean that performance is independent of the logical model
(normalized tables), and only dependent of the physical model (DBMS
internal structures). And with the current DBMSs the logical model is
tightly coupled to the physical model, what is a violation of the
principle of data independence.

That's why sometimes we need to corrupt (denormalize) the logical
designs in order to achieve better performance.

Regards
Alfredo

[Frans Bouma [C# MVP]]

Alfredo wrote:

On Mon, 10 May 2004 04:40:02 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

DataSet objects are intended to map an SQL database.

Where did you get this information? Afaik, they are intented to store
resultsets.

The resultsets returned from an SQL database, to manage them and to
submit the changes to the DBMS. The same as I said but with other
words.

I know they can be used with non SQL based data, but it is clear that
it is the main intention.

However a resultset has no relation with a physical set of entities.

SELECT * from A, B has no relation with A nor B, it forms a new entity, build
from A and B. So it's IMHO not used to map an SQL database, but simply there
to work with resultsets on one side (read) and to update rows in tables on
the other side (write).

I comment on your comment because I read the other day an article which
claimed there is no 'order' in a datatable because it has to mimic an Sql
Table and tables don't have an 'order'.

Subqueries can be as well optimized as joins.

No, because you have to perform different data-algebra expressions with
subqueries than with joins. Check the execution plans on northwind for:

I said that they can be as well optimized as joins, not that SQL
Server optimize them as well as joins ;-)

heh :) ok point taken. However, you can formulate subqueries which are hard
to optimize (especially when they're deep) due to the runtime-statistics
limitation.

Trace says: query 1 has a duration of 15 and 162 reads. QUery 2 has a
duration of 16 and 194 reads.

Query 2 could be transformed in Query 1 by the optimizer.

... in theory yes, however in practise it will take too much time in a lot
of cases. Which leaves out this optimization I think. But we're drifting off
topic ;)

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Frans Bouma [C# MVP]]

William Ryan eMVP wrote:

"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> wrote in message
news:xn***************@msnews.microsoft.com...

Joins are very cheap btw, as they can be very well optimized. Subqueries
on the other hand ARE still very expensive.

They can be cheap if done correctly, they can also be 'expensive' although
that's still a relative term. The point is that the implementation of a
model doesn't mean the model is weak. For years while i was too small to
read and before I was born, there was a fair amount of literature and
stereotypes that the relational model was mud just b/c the vendor
implementation didn't do X well for instance. Since I was sucking my thumb
at the time instead of using Oracle 1.0.1, I have to just look to what was
written and many themes and misconceptions seemed to be fairly commonplace.
But this didn't have anything to do with the model's failure and that was
ostensibly the analogy I was trying to make

Agreed. The relational model is 'weak' when you look at it from an OO POV:
you can't model inheritance for example without check constraints or even
values in tables. I wrote something about this a year ago or so, and realized
later that I was wrong: the relational model isn't weak because of that, it's
just 'different'.

FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Cor Ligthert]

Hi Frans,

I know, but when you subclass the DataTable class and add a property, it
will not be serialized into the data.

That makes your message clear for me.

Thanks, I will maybe have someday a look for it.

Cor

[Alfredo]

On Mon, 10 May 2004 06:07:58 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

There is no n-tier 'law', so saying it is about physical tiers is IMHO your
interpretation, not 'the' interpretation, because there is none.

You could say the same about almost everything in the IT world.

But n-tier systems have two logical tiers: Client and server.

Regards
Alfredo

[Alfredo]

On Mon, 10 May 2004 06:12:56 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

However a resultset has no relation with a physical set of entities.
Neither a SQL resutlset. Select * from A should not have relationship
with a physical set of entities.
SELECT * from A, B has no relation with A nor B, it forms a new entity, build
from A and B.
Select * from A, B is a virtual table, instead of a base table. But
this is a very common issue.
I comment on your comment because I read the other day an article which
claimed there is no 'order' in a datatable because it has to mimic an Sql
Table and tables don't have an 'order'.
There is order in a datatable because datatables are not perfect
"mappings" of SQL tables.
heh :) ok point taken. However, you can formulate subqueries which are hard
to optimize (especially when they're deep) due to the runtime-statistics
limitation.
Of course, but theoretically there are many possible ways to organize
the runtime-statistics. Each vendor has its own.
... in theory yes, however in practise it will take too much time in a lot
of cases. Which leaves out this optimization I think. But we're drifting off
topic ;)

It depends on how good the optimizer is. IMO the technology is still
in its infancy.
Regards
Alfredo

[Alfredo]

On Mon, 10 May 2004 06:16:37 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

Agreed. The relational model is 'weak' when you look at it from an OO POV:
Striking statement!

The Relational Model is the direct application of thousands of years
of accumulated knowledge in math and logic. It is the direct
application of Predicate Logic and Set Theory. Disciplines developed
by people like Aristotle, Boole, Cantor, Frege, Godel, Rusell, etc.
The Relational Model is a very solid mathematical framework.

Compare this with OO which has as many different interpretations as
practicioners.
you can't model inheritance for example without check constraints or even
values in tables.
I am afraid that what you mean is not inheritance at all.
I wrote something about this a year ago or so, and realized
later that I was wrong: the relational model isn't weak because of that, it's
just 'different'.

Indeed. The Relational Model is a data management approach. OO is a
set of coding guidelines. It is like to mix apples with oranges or
bacon with velocity as we say here :-)
Regards
Alfredo

[William Ryan eMVP]

Let's back way up here b/c this discussion is turning into something totally
different than the original question. Pretend there is magically no such
thing as RDBMS system...they just poof disappeared. This wouldn't affect
dataset one bit. You might counter that Rowstate would be unnecessary, but
that isn't really the case, who's to know what someone might need state
information for.

As such, DataSets have NOTHING to do with Relational theory. They may
appear to model it, they may appear to copy it's functionality, they may
even implement many of the rules, but they aren't necessarily RDBMS
structures or anything of the sort. Not using a DataRelation and having
Redundant is perfectly legal usage of DataSets. It may or may not be
recommended depending on what you want to do with the data, but that has
nothing to do with the dataset, it has to do with the end goal.

I could create a simple 2d object (person with 10 properties) that I can
model perfectly iwth a DataRow. All a Dataset is is a collection of
datatable which is a collection of datarows. I could do this because I don't
want to use new collection classes since these ones exist. I'm 'reusing'
existing objects to achieve my end. The fact that I may shove this data
into a database is ancilliary becuase I also may not.

To this end, I could easily employ datasets and say to hell with Relational
theory, Network model etc and still have a valid design. In addition, If I
only persistted say two of those fields and decided that I did want to send
them to the db, and it did match the structure of the back end, OR/M is not
only a natural fit, it's a very good one.

To that end I fail to see the point here?
"Alfredo" <al*****@nospam.es> wrote in message
news:40**************@msnews.microsoft.com...

On Mon, 10 May 2004 08:14:46 -0400, "William Ryan eMVP"
<do********@comcast.nospam.net> wrote:

Unfortunately many OO practicioners use the obsolete Network Model.

There are a lot of toerh misaaplications of OOP that are far more complex
than just this issue.

But this is an important issue IMO. For instance O/R mappers are tools
intended to apply the Network approach misusing the DBMSs as mere
storage mechanisms.

>On the contrary. However, the
>pragmatic reality made the theoritical application a 'contradiction'... >should I normalize to xNormal form or not? So many modelled tables to >performance issues over theoretical correctness even though the theory

was

>totally correct.

The dilemma is due to the lack of data independence of the current
DBMS products.

I'm not sure I understand what you mean here, but if your point is that
tightly coupling Data with the objects they represent is a problem, then yesI agree.

No, I mean that performance is independent of the logical model
(normalized tables), and only dependent of the physical model (DBMS
internal structures). And with the current DBMSs the logical model is
tightly coupled to the physical model, what is a violation of the
principle of data independence.

That's why sometimes we need to corrupt (denormalize) the logical
designs in order to achieve better performance.

Regards
Alfredo

[Earl]

Are we trolling Alfredo ;=) I have never read anything anywhere that a
reputable source would claim that the concept of "n-tier" had much if
anything to do with physical tiers. Most folks would consider the term
"n-tier" in the context of separating the business layer from the user and
data layers. Since those might be physically implemented all on the same
machine, "n-tier" is clearly a term to describe a logical implementation.
But a client-server relationship is "n-tier" also, distinctly not only a
logical implementation, but most often a physical implementation also. I'll
leave it to others more experienced than I to expound.

"Alfredo" <al*****@nospam.es> wrote in message
news:40***************@msnews.microsoft.com...

On Mon, 10 May 2004 06:07:58 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

There is no n-tier 'law', so saying it is about physical tiers is IMHO yourinterpretation, not 'the' interpretation, because there is none.

You could say the same about almost everything in the IT world.

But n-tier systems have two logical tiers: Client and server.

Regards
Alfredo

[Frans Bouma [C# MVP]]

Alfredo wrote:

On Mon, 10 May 2004 06:07:58 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

There is no n-tier 'law', so saying it is about physical tiers is IMHO
your interpretation, not 'the' interpretation, because there is none.

You could say the same about almost everything in the IT world.

But n-tier systems have two logical tiers: Client and server.

but the BL is a client of the DAL and a server to the GUI client tier :),
that's why I was saying, the differences in tiers are semantical, not
necessarily client/server

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Frans Bouma [C# MVP]]

Alfredo wrote:

On Mon, 10 May 2004 08:14:46 -0400, "William Ryan eMVP"
<do********@comcast.nospam.net> wrote:

Unfortunately many OO practicioners use the obsolete Network Model.

There are a lot of toerh misaaplications of OOP that are far more complex
than just this issue.

But this is an important issue IMO. For instance O/R mappers are tools
intended to apply the Network approach misusing the DBMSs as mere
storage mechanisms.

I don't think every O/R mapper does that, only the ones following
Fowler/Evans' Domain model. (note: I don't follow that approach)

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Frans Bouma [C# MVP]]

Alfredo wrote:

On Mon, 10 May 2004 06:16:37 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

Agreed. The relational model is 'weak' when you look at it from an OO
POV:

Striking statement!

The Relational Model is the direct application of thousands of years
of accumulated knowledge in math and logic. It is the direct
application of Predicate Logic and Set Theory. Disciplines developed
by people like Aristotle, Boole, Cantor, Frege, Godel, Rusell, etc.
The Relational Model is a very solid mathematical framework.

I think that is a bit too much. Codd did most of the work, and before that,
there was mathematical theory, but not applyable to databases directly.
Agreed, most theoretical basis is founded way before Codd walked the earth,
but I find it a bit too much to give ancient mathematicans the credit for the
relational model ;)

you can't model inheritance for example without check constraints or even
values in tables.

I am afraid that what you mean is not inheritance at all.

( <- == is-a )

Person <- Employee <- Manager <- CEO
Person <- Employee <- Clerk
Person <- Employee <- Accountant

Now, if you set this up in NIAM or ORM (Halpin) you will use
supertypes/subtypes and which allow you to define relations directly to
'Manager' for example.

When you want to project this onto a relational model, you can't define is-a
relationships or supertype/subtypes. You can 'try', but it is very hard.
Nijssen/Halpin mention 2 ways:
1) flatten the supertype/subtype hierarchy and store them all in 1 table,
with all attributes of all types in the hierarchy in that table, and
attributes which are defined with a lower type than the root supertype are
nullable. Furthermore, add a column which identifies the type of the entity
in a particular row.
2) define 1 table per subtype and add an FK constraint from the PK of the
subtype table to the PK of its supertype table (not THE supertype table!)

1) requires values in its type column to interpret which type the row really
has. This is thus not modelable in the relational model: without data in that
column, there is no hierarchy, and the hierarchy is in the data, not in the
model. In other words you can't model inheritance this way, even though it IS
inheritance.
2) is close, however it doesn't symbolizes a hierarchy per se, because the FK
constraint just illustrates 'relationship between attributes' not an is-a
relationship. Retrieving a complete 'type' requires reads from 1 (person) or
more tables (rest), which is not modelable: I can read a row from 'Manager'
without the necessity to read its related row in Employee: i.e. the rows are
related but not seen as a unit, while we do see them as a unit in our
abstract supertype/subtype hierarchy.
FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Alfredo]

On Mon, 10 May 2004 10:28:51 -0500, "Earl" <brikshoe<at>comcast<.>net>
wrote:

Are we trolling Alfredo ;=)
No.
I have never read anything anywhere that a
reputable source would claim that the concept of "n-tier" had much if
anything to do with physical tiers.
I don't know any reputable source who writes about n-tiers. It is all
very weak.
Most folks would consider the term
"n-tier" in the context of separating the business layer from the user and
data layers.
A nonsense. It is impossible to separate the business layer from the
database layer because they are the same. What is possible is to
separate the logical database layer from the storage mechanism and
DBMSs are intended to do that.

An Application Server is nothing but a DBMS that uses another DBMS
behind the scenes as the storage mechanism. Then we have again a
client and a server. The backend DBMS used for storage is an
implementation detail. It is "encapsulated" and out of the logical
level.
Since those might be physically implemented all on the same
machine, "n-tier" is clearly a term to describe a logical implementation.
No, you may have many physical tiers in the same machine.
But a client-server relationship is "n-tier" also

Of course, a client-server system may have many physical tiers. If
they have more than 2 they are called "n-tier" systems.
Regards
Alfredo

[Alfredo]

On Mon, 10 May 2004 11:30:21 -0400, "William Ryan eMVP"
<do********@comcast.nospam.net> wrote:

Let's back way up here b/c this discussion is turning into something totally
different than the original question.
Something very frequent in the newsgroups.
As such, DataSets have NOTHING to do with Relational theory.
This is unfortunately true.
They may
appear to model it, they may appear to copy it's functionality, they may
even implement many of the rules, but they aren't necessarily RDBMS
structures or anything of the sort.
Nobody said the contrary. It is clear that datasets are intended to
map SQL databases, but you can do all you want with them.
To this end, I could easily employ datasets and say to hell with Relational
theory, Network model etc and still have a valid design.

Of course, but to use a network design in the 21 century does not make
a lot of sense.
Regards
Alfredo

[Alfredo]

On Mon, 10 May 2004 08:36:43 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

But this is an important issue IMO. For instance O/R mappers are tools
intended to apply the Network approach misusing the DBMSs as mere
storage mechanisms.
I don't think every O/R mapper does that, only the ones following
Fowler/Evans' Domain model.

Which ones don't?

I only know these O/R mappers.
(note: I don't follow that approach)

Good for you!

Regards
Alfredo

[Alfredo]

On Mon, 10 May 2004 08:33:42 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

But n-tier systems have two logical tiers: Client and server.

but the BL is a client of the DAL and a server to the GUI client tier :),

But the DAL does not exist for the GUI. It is hidden or encapsulated.
That's why I said that there are only two visible logical layers.

In the case of a distributed DBMS is the same. A properly designed
distributed database should appear to the clients as a single
database. Client-Server again.
Regards
Alfredo

[Frans Bouma [C# MVP]]

Alfredo wrote:

On Mon, 10 May 2004 08:33:42 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

But n-tier systems have two logical tiers: Client and server.
but the BL is a client of the DAL and a server to the GUI client tier :),

But the DAL does not exist for the GUI. It is hidden or encapsulated.
That's why I said that there are only two visible logical layers.

You can have multiple tiers at the same tier level, hidden by a facade,
however the facade calls into different tiers.
In the case of a distributed DBMS is the same. A properly designed
distributed database should appear to the clients as a single
database. Client-Server again.

however these 'clients' are servers for other clients. So strictly thinking
in 'client' and 'server' is not that great. Better is: 'consumer-role' and
'producer-role' in a given 'situation'.

FB
--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[Frans Bouma [C# MVP]]

Alfredo wrote:

On Mon, 10 May 2004 08:36:43 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

But this is an important issue IMO. For instance O/R mappers are tools
intended to apply the Network approach misusing the DBMSs as mere
storage mechanisms.
I don't think every O/R mapper does that, only the ones following
Fowler/Evans' Domain model.

Which ones don't?

mine :)
I only know these O/R mappers.

O/R mappers are IMHO for solving overhead code: how to work with data with
OO constructs. You need overhead code to make that happen.

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[William Ryan eMVP]

"Alfredo" <al*****@nospam.es> wrote in message
news:40***************@msnews.microsoft.com...

On Mon, 10 May 2004 11:30:21 -0400, "William Ryan eMVP"
<do********@comcast.nospam.net> wrote:

Let's back way up here b/c this discussion is turning into something totallydifferent than the original question.
Something very frequent in the newsgroups.

As such, DataSets have NOTHING to do with Relational theory.

This is unfortunately true.

They may
appear to model it, they may appear to copy it's functionality, they may
even implement many of the rules, but they aren't necessarily RDBMS
structures or anything of the sort.

Nobody said the contrary. It is clear that datasets are intended to
map SQL databases,

I respectfully disagree. If their intended purpose was to map back to SQL
databases, then what explains the tremendous support for XML and the fact
that you don't need to use a DB at all? It's a datasource that they are
meant to map back to, and that datasource can be a flat file, csv etc.

If they are clearly intended to map back to SQL Databases and aren't equally
intended to map to other data sources, then why can you use an Excel Sheet
or csv file, as flat and anti-sql as they get, Exactly like you would a SQL
DB, particularly in regard to the dataset. If anything you could make that
argument about a dataadapter, but again that's flawed because of the point I
just made.

If SQL Databases are the intended purpose, what explains the support for Web
Services, one of the highlights of ADO.NET that could write bits and pieces
of data to x number of hetergeneous data sources in part or in their
entirety? You could (and many do) write pieces of the Data retrieved form
th edataset ws for instance to an oracle/sql server/access db (which are all
obviously SQL) as well as HTML and XML Files which could be easily consumed
by say Infopath. I do it daily and it's in no way irregularl usage.

Moroever, you'll notice the word DataSource used extensively in the
documentation, not SQL Compliant Database. MS went through a good bit of
effort to draw this distinction precisely b/c it wanted to eliminate
confusion like this.

but you can do all you want with them.

To this end, I could easily employ datasets and say to hell with Relationaltheory, Network model etc and still have a valid design.
Of course, but to use a network design in the 21 century does not make
a lot of sense.

I wasn't saying it did..hence the statement Network model etc. I coudl opt
totally out of all of these particular models and used a declarative model
coupled with a any concept I want, I'm free to invent it for that matter..

Regards
Alfredo

[Earl]

One of my clients (who used to be a CFO at a big software house) often
states that "software is an opinion". Being conceptual, the entire "layer"
idea must be -- by definition -- a logical implementation.

I do agree with the the thought that "you may have many physical tiers in
the same machine."

"Alfredo" <al*****@nospam.es> wrote in message
news:40***************@msnews.microsoft.com...

On Mon, 10 May 2004 10:28:51 -0500, "Earl" <brikshoe<at>comcast<.>net>
wrote:

Are we trolling Alfredo ;=)

No.

I have never read anything anywhere that a
reputable source would claim that the concept of "n-tier" had much if
anything to do with physical tiers.

I don't know any reputable source who writes about n-tiers. It is all
very weak.

Most folks would consider the term
"n-tier" in the context of separating the business layer from the user anddata layers.

A nonsense. It is impossible to separate the business layer from the
database layer because they are the same. What is possible is to
separate the logical database layer from the storage mechanism and
DBMSs are intended to do that.

An Application Server is nothing but a DBMS that uses another DBMS
behind the scenes as the storage mechanism. Then we have again a
client and a server. The backend DBMS used for storage is an
implementation detail. It is "encapsulated" and out of the logical
level.

Since those might be physically implemented all on the same
machine, "n-tier" is clearly a term to describe a logical implementation.

No, you may have many physical tiers in the same machine.

But a client-server relationship is "n-tier" also

Of course, a client-server system may have many physical tiers. If
they have more than 2 they are called "n-tier" systems.
Regards
Alfredo

[Guinness Mann]

Jay B. Harlow [MVP - Outlook] wrote:

Martin's book discusses when you should consider one over the other, plus various patterns to support an OO approach with either (DataSet or Domain
object) approach.
...
However if my "Domain Objects" had heavy logic to them, then I would use a
Domain Model and Data Mapper approach. See:
http://www.martinfowler.com/eaaCatalog/domainModel.html &
http://www.martinfowler.com/eaaCatalog/dataMapper.html patterns

Note: My Data Mappers would use a DataReader to read an row from the
database to create a new Domain object, passing the information for a row to
the constructor of the Domain object.

Hear, hear! All "business logic" is not necessarily what we
traditionally think of as "business" related. Even when it is, it often
isn't tabular. Think about a manufacturing application that has to
handle bills of assembly. The domain objects will almost assuredly
form some kind of tree structure while the native database
implementation will just as assuredly be tables.

In such a case the business objects will probably follow the composition
pattern using a data mapper to create each node.

The whole world isn't invoices and inventory.

-- Rick

[Alfredo]

On Mon, 10 May 2004 08:55:21 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

I think that is a bit too much. Codd did most of the work
Of course. Codd had the genial idea of applying thousands of years of
advances in maths to the data management field and it has an inmense
merit.
, and before that,
there was mathematical theory, but not applyable to databases directly.
Agreed, most theoretical basis is founded way before Codd walked the earth,
but I find it a bit too much to give ancient mathematicans the credit for the
relational model ;)
Of course, I completely agree with you. But I was talking about the
origins of The Relational Model's strength.

> you can't model inheritance for example without check constraints or even
> values in tables.

I am afraid that what you mean is not inheritance at all.

( <- == is-a )

Person <- Employee <- Manager <- CEO
Person <- Employee <- Clerk
Person <- Employee <- Accountant

Now, if you set this up in NIAM or ORM (Halpin) you will use
supertypes/subtypes and which allow you to define relations directly to
'Manager' for example.

But NIAM and ORM are not relational. BTW I never have found them very
useful.

With The Relational Model you have to represent all these information
in several relations (tables). But it is not inheritance. It is an
application of Predicate Logic. Each relation (table) represents a
predicate and each tuple (row) a logical proposition.

Table inheritance does not make sense in The Relational Model. And it
is completely different to the OO class inheritance.
When you want to project this onto a relational model, you can't define is-a
relationships or supertype/subtypes.
Wen you project this onto a relational design the ORM types and
subtypes don't make sense anymore. You have to work in terms of
predicates and propositions.

You can define is-a relationships in many ways.

For instance:

create table IsA(name varchar(20), position varchar(20), primary
key(name, position));

insert into IsA values ('John', 'Manager');

This tuple means that John is a manager.

Relationships are relations and The Relational Model is all about
relations!

Another way:

create table Managers(name varchar(20) primary key);

insert into Managers values ('John');

This means: John is a manager.
You can 'try', but it is very hard.
Nijssen/Halpin mention 2 ways:
1) flatten the supertype/subtype hierarchy and store them all in 1 table,
with all attributes of all types in the hierarchy in that table, and
attributes which are defined with a lower type than the root supertype are
nullable. Furthermore, add a column which identifies the type of the entity
in a particular row.
Horrible practice that breaks The Relational Model. The result is not
a relational design.

BTW "flatten" does not make sense if you are talking about The
Relational Model. Predicates and propositions can't be flat.
2) define 1 table per subtype and add an FK constraint from the PK of the
subtype table to the PK of its supertype table (not THE supertype table!)
One table or more than one. But you can skip ORM and to do that
directly thinking in relational terms.
2) is close, however it doesn't symbolizes a hierarchy per se, because the FK
constraint just illustrates 'relationship between attributes' not an is-a
relationship.

The relation predicates might simbolize anything you want. The FK
constraint is just an integrity constraint. An is-a relationship is a
relation like any other. They are trivial to represent with The
Relational Model.

create table Employees(Id integer primary key, name varchar(20) , wage
numeric);

create table Managers(id integer primary key, department varchar(20),
foreign key (id) references Employees(id));

insert into Employees value(1, 'John', 50000);

This means: John is the employee with the Id 1 and earns 50.000. And
of course it stablishes that John is-an employee.

insert into EmpManagers values (1, 'Accounting');

This means: the employee with Id 1 is the manager of the accounting
department.

From these two propositions you can infere that John is-a manager. And
the DBMS too, if you declare the inference rules:

create view Managers as select * from Employees e, EmpManagers m where
e.Id = m.Id;

Select * from managers.

This should return:

Id Name Wage Department
-------------------------------------------
1 John 50000 Accounting

This means John is an employee, has the Id 1, earns 50.000 and he is
the manager of the accounting department.

Regards
Alfredo

[Alfredo]

On Mon, 10 May 2004 10:19:47 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

In the case of a distributed DBMS is the same. A properly designed
distributed database should appear to the clients as a single
database. Client-Server again.
however these 'clients' are servers for other clients. So strictly thinking
in 'client' and 'server' is not that great.

I agree it is not very good terminology.
Better is: 'consumer-role' and
'producer-role' in a given 'situation'.

I prefer applications-DBMS
Regards
Alfredo

[Alfredo]

On Mon, 10 May 2004 10:21:02 -0700, "Frans Bouma [C# MVP]"
<pe******************@xs4all.nl> wrote:

Which ones don't?
mine :)

I will look it.

I only know these O/R mappers.

O/R mappers are IMHO for solving overhead code: how to work with data with
OO constructs. You need overhead code to make that happen.

This is again the problem of the lack of precise terminology.

According to your definition ADO.NET could be considerd an O/R mapper.
And I don't see any problem in that.
Regards
Alfredo

[Hani Atassi]

Just a thought..

I did OOP represenation of a dataset before using DataViews.. Basically, my classes holds views of the data in a dataset using both DataView and DataRow..
There are problems with this though in the case of serializing because DataViews cannot be serialized..

Regards,