I have to disagree with Ryan - datatables in a dataset WERE designed to be like local tables you can manipulate and create views from. Think of a dataset as a database on a local SQL server. Your datatables are the tables within that database. You can then create dataviews of a datatable - as you would create views of tables in the database - that allow you to sort and filter your datatable. Changes to the datatable obviously cascade down in realtime to the dataview. Similarly, changes to the dataview are pushed back to the datatable.
Key differentiator: .NET assumes that by the time your data hits the datatable you've already done the denormalisation. It would be silly to pull your lookup tables across to the application and try denormalise there. That having been said, it is still often advantageous to pull a bigger set of denormalised data to the smart client application, and then create a dataview or dataviews of the data. It's (generally, I know there are exceptions) MUCH faster to let the user click on a bunch of checkboxes that filter the data and merely update a dataview, than to change the LINQ or T-SQL and resubmit it to the database. An initial wait of a few seconds for data to stream is always more preferable than a few seconds for each filter change.
I used datatables and dataviews quite extensively in an open-source project (this is like the third time I've punted this on here, but I'm too lazy to Google for other examples) that you may find informative: http://www.codeplex.com/scriptio
Ciao,
Riccardo
And so the kief looked and lo, it was kief.