An in-memory or transient representation of tabular data, usually the result of a query issued by an application or data-related tool.
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.
for full description
Also known as: RowSet?
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 ResultSet
s, 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 Record
Item 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
See also TableModule