0

Is it better to use multiple calls to stored procedures that retrieve multiple DataTables or a single stored procedure that retrieves a single DataSet?

I have been told by a more experienced colleague that there are known issues and bugs with using DataSet, that it makes code not readable and that it is generally better to use DataTables and multiple calls to stored procs.

Searching online I have not been able to find documented issues and bugs that trouble DataSet, while also learning that it is widely used.

mi105
  • 149
  • 1
  • 9
  • 1
    Ask your more experienced colleague for specific documentation so you can be sure to address these issues correctly. He'll probably get evasive, blow smoke at you, and change the subject. He might send you an article or two that turn out to be totally unrelated, or directly contradict his claims. Unless he gives you something concrete and relevant (and he might!), he's a fool and you should politely listen to what he has to say -- and then ignore it. Just out of curiosity, does this guy have a weird preoccupation with immutability? – 15ee8f99-57ff-4f92-890c-b56153 May 18 '17 at 15:33
  • 1
    @EdPlunkett I respect this colleague, especially since he is my superior, so I would politely ask you to not call him names. It's just that usage of DataSet is so common that it bugs me why are we not supposed to use it. It's probably a matter of personal preference and code style – mi105 May 18 '17 at 15:43
  • I appreciate your desire not to sling mud at a senior colleague. CDove, below, has a more tactful way of looking at it than mine. But the bottom line is that your suspicion is correct: The guy is telling you something that isn't true. If you're forbidden to use the class at work, don't. They sign your checks. But don't doubt your own judgment here. – 15ee8f99-57ff-4f92-890c-b56153 May 18 '17 at 15:48
  • 2
    @MilosMilosavljevic Please see my answer. It's unfortunately a bad habit that *all* developers get into at some point (and have to kick ourselves out of) to say something sucks because we haven't figure it out yet. It comes from modern software development having a lot of flimsy job security. – CDove May 18 '17 at 15:49
  • Although Michael answer describes one possible issue (when they are used as part of the signature of a service call) I accepted CDove answer because it better fits description of my question where the context is set on issues one might face with Dataset in contrast with DataTable. – mi105 May 19 '17 at 15:51
  • Also, the issue Michael presented fits into CDove answer where he states "When working with any database, though, the question becomes "how can I do the most work with the least number of database calls while not impacting performance of either my app or the server, AND over a network connection". The answer to that should drive your data collection method." – mi105 May 19 '17 at 15:52

2 Answers2

7

Ahh. I've run into this sort of thing before. Allow me to translate what your colleague told you.

There are known issues and bugs with using DataSet, that it makes code not readable and that it is generally better to use DataTables and multiple calls to stored procs.

Means

As the more senior developer here, I haven't worked with DataSets enough to know how to use them effectively. I remember what people said about them when they were brand new, but I'm an old dog that doesn't learn new tricks, and I want you to do things how I do them so I don't look bad.

It's regrettably common. Where I work now, the guy who used to be the web developer here tried to convince me that Linq was "too new" and "full of bugs" because (as I later discovered) he couldn't read a Lambda expression. Blew his damn mind when I showed him C# implied property fields.

If you're using them right and commenting your code, DataSets aren't unreadable or buggy. DataTables with stored procedure calls are just as valid, but a DataSet is basically a collection of DataTables on steroids. You're probably filling both with stored procedures or straight up LINQ to SQL. When working with any database, though, the question becomes "how can I do the most work with the least number of database calls while not impacting performance of either my app or the server, AND over a network connection". The answer to that should drive your data collection method.

CDove
  • 1,940
  • 10
  • 19
1

One problem I have witnessed with DataSets are when they are used as part of the signature of a service call(.NET Remoting, WCF and Traditional Web Services are example I have seen).

The reason this is a bad practice is because the payload of a DataSet are large which hurts response time.

Another reason is Microsoft in the past have not always made DataSets backwards compatible from one version of .NET to another. So if you are developing an application in .NET 4.0 and the service you are calling is running on .NET 1.1, it will likely break when passing a .NET 4.0 DataSet to a service accepting a .NET 1.1 DataSet because of backwards comparability issues.

null_pointer
  • 1,779
  • 4
  • 19
  • 38
  • If your .Net 1.1 service fails to accept a .Net `DataSet`, the problem isn't that you used a `DataSet`, it's that you still have a service that was made from almost 2-decade-old technology. – CDove May 19 '17 at 14:22
  • Beyond that, some of what you've said here is just flat inaccurate (such as DataTables providing greater compatibility with .Net 1.1). Sources: http://stackoverflow.com/questions/2250/datatable-vs-dataset, https://social.msdn.microsoft.com/Forums/en-US/47c62835-6187-4251-8d44-f9b8dca3406b/dataset-vs-datatable-performance?forum=netfx64bit,https://msdn.microsoft.com/en-us/library/ss7fbaez.aspx – CDove May 19 '17 at 14:29
  • You can't always control the endpoint you are communicating with so saying someone should upgrade is a moot point. The point of original post is about known issues with `DataSets` and I pointed out my own experiences. I am also not inaccurate on anything I said. I also did not say anything about `DataTables` providing greater compatibility with .NET 1.1. – null_pointer May 19 '17 at 14:39