I'm working on an application which has a similar architecture to Taskvision. I notice it uses multiple datasets. Why not use a single dataset for all tables? What are the advantages/disadvantages of each approach?

Thanks in advance,

Lee

I am developing an application with exactly 90 different DataTables. and 3 TypedDataSets, one with aprox 50 tables one with aprox 30, and one with aprox 20.
But I am thinking about change that and use only one DataSet.
The reasons:
-Well you can not have relationships between tables in 2 differents datasets. And in real world application almost everything is related with everything else, and if the right way of doing things is using multiple dataset ¿why DataReltion can NOT work INTER-Dataset'
-Because you cannot have DataRelations you cannot have contraints between your data.
-I built a Data Persistency Manager that analyses the structure of a dataset and its data and  automatically translates all of its changes to SQL, so I don't have to manually mantain over 90 OleDbDataAdapters and over 270 OleDbCommands, but to be able to do that I need to know all the relationships between the datatables, and if they are in different dataset, I cannot know their relationship on runtime.
-Different datasets are also a bad idea because there is NO WAY to tell to 2 TypedDataSets that if they both have a DataTable "Customer", the generated "CustormerDataRow" class it IS THE SAME, so if you write code for CustomerDataRow in TypedDataSet1, you wont be able to use it with CustomerDataRow in TypedDAtaSet2, so you end up writing code to deal only with untyped DataRows, and If that is the way of doing things ¿for what do I want a TypedDataSet anyway?


¿Why am I currently using 3 datasets?
-Well, I think the developers of the visual designer think that no one is going to build anything else than small apps with less than 20 tables, and that is why it does not have Zooming and it is really hard to mantain a real life application xsd with such a poor designer.

¿What do I think about DataSets?
They are a bad solution for this problem, they are just a relational way of representing a copy of the data in memory,and you cannot embbed behavior inside them, because they are really hard to inherit in a good way (almost NOTHING is Virtual), you cannot load the related data that you need, only when you need it because it has no support for lazy loading, you cannot write the algorithm for a calculated datacolumn in C#, you have to use the unexpressive "Expression" column, you cannot automatically save you dataSet, it is hard to work visually with a Dataset with 2 Master - Detail Forms, and many other problems I have to deal with every day.

System.Data is not an ObjectRelational Framework, maybe in 1 year, maybe in 2 years ObjectSpaces will be released, and then we are going to make real Object Oriented Data Programming, in the mean while, am starting to build my own ObjectRelational Framework, and am taking a close look at projects like Bamboo and .NET Hibernate, or at Thona's EntityBroker.

The idea of Data Persisitency Manager is an interesting one. How have you achieved this?

One thing that strikes me about using a single typed dataset pulled from a web service: Does it mean dragging the entire schema across the wire whenever you update it? If you only wanted a few rows from a specific table, would you wind up dragging lots of unecessary additional information with it?

Lee

Hi!
Well I navigate de DataRelations of the DataSet, and generate DataAdapters in runtime, to do that I also developed my own CommandBuilder ("CommandConstructor") that is "ADO.NET Provider Agnostic". (To do this I had to write lots and lots of code, but after that is a lot easier to mantain than dragging and droping dozens of Adapters each time I change my relational model because the Client is not happy with the documented specifications, or wants a new query, or something else).

Well, yes, you can end up dragging some "extra" information that you don't need, sometimes just a little, some times a lot, depending on the parent relations of the rows of the table you are loading in to the DataSet, Why? because you if you can not "EnforceConstraints" in a DataSet that has a DataRow with out a parent, and DataSet do not support Lazy Loading of related DataRows.

So, as good as my Data Persisitency Manager is, it is not an Object Relational Mapping Framework, but I have started my own Object Relational Mapping Framework, and I think in the near future (1 to 3 Months) I will be able to do this without dragging unecessary information.

bye
Luxspes