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

[Alfredo]

On Mon, 10 May 2004 02:05:31 -0700, "Frans Bouma [C# MVP]"
<pe************ ******@xs4all.n l> 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.Strin gWriter
ds.WriteXml(sw)
Dim mystring As String = sw.tostring
///
Deserialize
\\\
Dim sr As New System.IO.Strin gReader(mystrin g)
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.n l> 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.Custo merID = Orders.Customer ID
INNER JOIN Employees
ON Orders.Employee ID = Employees.Emplo yeeID
Where Employees.Count ry = '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.n l> 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
misunderstandin gs 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.n l> 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.n l> wrote in message
news:xn******** *******@msnews. microsoft.com.. .

William Ryan eMVP wrote:

"cody" <pl************ *************@g mx.de> wrote in message
news:%2******** *******@TK2MSFT NGP12.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,Positi ons, 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.n l> 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.m icrosoft.com...

On Sun, 9 May 2004 22:39:08 -0400, "William Ryan eMVP"
<do********@com cast.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.Strin gWriter
ds.WriteXml(sw)
Dim mystring As String = sw.tostring
///
Deserialize
\\\
Dim sr As New System.IO.Strin gReader(mystrin g)
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