Record Set

An in-memory or transient representation of tabular data, usually the result of a query issued by an application or data-related tool.

A RecordSet is an in-memory structure that looks exactly like the result of a SQL query, but which can be generated and manipulated by parts of the system other than the relational database system.

See http://martinfowler.com/eaaCatalog/recordSet.html for full description

Also known as: RowSet?, DataSet, ResultSet

So what is a RecordSet ??? An in-memory representation of "tabular" data is, we all know, a bidimensional array, no need to label that as a pattern. We might attach string labels to column indices to make it more "table-like". Is it that, or is it rather an array of hashmaps, or is a set of hasmaps, or is it really a set of records where a record is ... ? What makes this organization interesting, and what interfaces should this aggregate expose in order to be both interesting and useful? MartinFowler left me puzzled on these questions, he doesn't seem to define any solution at all, the only concrete recommendation is to make something that "looks exactly like the results of a query". And the UML on top of that page is inaccurate.

My recommendation is to read both the help and the actual design/source code behind DelphiLanguage: TDataField/TDataSource/TDataSet/TTable/TQuery/TStoredProcedure set of classes, or alternatively the documentation for ADO.NET. --CostinCozianu

Is it required that a RecordSet be in-memory? If the SQL query returns a lot of data that's definitely not what you want. Java ResultSets, for one, are not always in-memory for this reason.

In our database product, a RecordSet has a specified interface similar to a container class. In different circumstances, it contains different representations of the records. Sometimes it's a bit-vector of record ids if the set is large and unsorted, sometimes it's an array of sorted ids, sometimes it's the record data itself. The interface hides the details. We have a separate RecordItem class for accessing the contents of a particular record in a C++ typesafe manner. -- IanOsgood

Using a single-record RecordSet as an all-purpose abstraction for business data is a common AntiPattern in my experience. It's convenient because it bypasses TypeSafety; it's inconvenient because it bypasses TypeSafety.

This sounds like a classic dynamic-versus-static-typing HolyWar issue. I am not a fan of static/strong typing. Without repeating those debates, I will point out something specific to record-sets from DB's: the database is meant to be used by multiple languages, and TypeSafety tends not to be transferrable across languages. Thus, I don't see what the alternative is. One can wrap a result into language-specific type wrappers, but it has to be recreated for each using language. --top

IsRecordSetAnInterestingPattern?

CategoryPattern, CategoryTable