Editing Record (computer science) (section)

==History==

[[File:1880 census Edison.gif|thumb|upright|Journal sheet from [[1880 United States census]], showing tabular data with rows of data, each a record corresponding to a single person.]]
The concept of a record can be traced to various types of [[Table (information)|table]]s and [[ledger]]s used in [[accounting]] since remote times.  The modern notion of records in computer science, with fields of well-defined type and size, was already implicit in 19th century mechanical calculators, such as [[Charles Babbage|Babbage]]'s [[Analytical Engine]].<ref>{{cite journal |last1=Bromley |first1=Allan |title=Charles Babbage's Analytical Engine, 1838 |journal=IEEE Annals of the History of Computing |date=October 1998 |volume=20 |issue=4 |pages=29–45 |doi=10.1109/85.728228 |s2cid=2285332 |url=https://dl.acm.org/citation.cfm?id=612744 |access-date=23 September 2018|url-access=subscription }}</ref><ref>{{cite web |last1=Swade |first1=Doron |title=Automatic Computation: Charles Babbage and Computational Method |url=http://www.rutherfordjournal.org/article030106.html |website=The Rutherford Journal |access-date=23 September 2018}}</ref>

[[File:Hollerith Punched Card.jpg|thumb|Hollerith [[punched card]] (1895)]]
The original machine-readable medium used for data (as opposed to control) was the [[punch card]] used for records in the [[1890 United States census]]: each punch card was a single record. Compare the journal entry from 1880 and the punch card from 1895. Records were well-established in the first half of the 20th century, when most data processing was done using punched cards. Typically, each record of a data file would be recorded on one punched card, with specific columns assigned to specific fields. Generally, a record was the smallest unit that could be read from external storage (e.g., card reader, tape, or disk). The contents of punchcard-style records were originally called "unit records" because punchcards had pre-determined document lengths.<ref name=":0">{{Cite book |title=Encyclopedia of computer science |date=2003 |publisher=Wiley |editor=Edwin D. Reilly |editor2=Anthony Ralston |editor3=David Hemmendinger |isbn=978-1-84972-160-8 |edition=4th |location=Chichester, UK |oclc=436846454}}</ref> When storage systems became more advanced with the use of [[Hard disk drive|hard drives]] and [[magnetic tape]], variable-length records became the standard. A variable-length record is a record in which the size of the record in bytes is approximately equal to the sum of the sizes of its fields. This was not possible to do before more advanced storage hardware was invented because all of the punchcards had to conform to pre-determined document lengths that the computer could read, since at the time the cards had to be physically fed into a machine.

Most [[machine language]] implementations and early [[assembly language]]s did not have special syntax for records, but the concept was available (and extensively used) through the use of [[index register]]s, [[indirect addressing]], and [[self-modifying code]]. Some early computers, such as the [[IBM 1620]], had hardware support for delimiting records and fields, and special instructions for copying such records.

The concept of records and fields was central in some early file [[sorting]] and [[tabulation|tabulating]] utilities, such as [[IBM RPG|IBM's Report Program Generator (RPG)]].

<!--- link from COBOL article -->
{{Visible anchor|[[COBOL]]}} was the first widespread [[programming language]] to support record types,<ref>{{cite book |last1=Sebesta |first1=Robert W. |title=Concepts of Programming Languages |year=1996 |publisher=Addison-Wesley Publishing Company, Inc. |isbn=0-8053-7133-8 |page=[https://archive.org/details/conceptsofprogra00sebe/page/218 218] |edition=Third |url-access=registration |url=https://archive.org/details/conceptsofprogra00sebe/page/218 }}</ref> and its record definition facilities were quite sophisticated at the time. The language allows for the definition of nested records with alphanumeric, integer, and fractional fields of arbitrary size and precision, and fields that automatically format any value assigned to them (e.g., insertion of currency signs, decimal points, and digit group separators). Each file is associated with a record variable where data is read into or written from. COBOL also provides a <code>MOVE</code> <code>CORRESPONDING</code> statement that assigns corresponding fields of two records according to their names.

The early languages developed for numeric computing, such as [[FORTRAN]] (up to [[FORTRAN IV]]) and [[ALGOL 60]], did not support record types; but later versions of those languages, such as [[FORTRAN 77]] and [[ALGOL 68]] did add them. The original [[Lisp programming language]] too was lacking records (except for the built-in [[cons cell]]), but its [[S-expression]]s provided an adequate surrogate.<!--What about Common Lisp?--> The [[Pascal programming language]] was one of the first languages to fully integrate record types with other basic types into a logically consistent type system.<!-- Unsure, ALGOL 68 or C may have come first?--> The [[PL/I]] language provided for COBOL-style records. The [[C (programming language)|C]] language provides the record concept using [[struct (C programming language)|struct]]s. Most languages designed after Pascal (such as [[Ada (programming language)|Ada]], [[Modula]], and [[Java (programming language)|Java]]), also supported records.

Although records are not often used in their original context anymore (i.e. being used solely for the purpose of containing data), records influenced  newer [[object-oriented programming]] languages and [[relational database]] management systems. Since records provided more modularity in the way data was stored and handled, they are better suited at representing complex, real-world concepts than the [[primitive data type]]s provided by default in languages. This influenced later languages such as [[C++]], [[Python (programming language)|Python]], [[JavaScript]], and [[Objective-C]] which address the same modularity needs of programming.<ref>{{Cite book |last1=Leavens |first1=Gary T. |last2=Weihl |first2=William E. |title=Proceedings of the European conference on object-oriented programming on Object-oriented programming systems, languages, and applications - OOPSLA/ECOOP '90 |chapter=Reasoning about object-oriented programs that use subtypes |date=1990 |chapter-url=http://dx.doi.org/10.1145/97945.97970 |pages=212–223 |location=New York, New York, USA |publisher=ACM Press |doi=10.1145/97945.97970|isbn=0-201-52430-9 |s2cid=46526 |url=https://lib.dr.iastate.edu/cs_techreports/92 }}</ref> [[Object (computer science)|Objects]] in these languages are essentially records with the addition of [[Method (computer programming)|methods]] and [[Inheritance (object-oriented programming)|inheritance]], which allow programmers to manipulate the way data behaves instead of only the contents of a record. Many programmers regard records as obsolete now since object-oriented languages have features that far surpass what records are capable of. On the other hand, many programmers argue that the low overhead and ability to use records in [[assembly language]] make records still relevant when programming with low levels of [[Abstraction (computer science)|abstraction]]. Today, the most popular languages on the [[TIOBE index]], an indicator of the popularity of programming languages, have been influenced in some way by records due to the fact that they are object oriented.<ref>{{Cite web |title=Index: The Software Quality Company |url=https://www.tiobe.com/tiobe-index/ |access-date=2022-03-01 |website=TIOBE.com}}</ref> Query languages such as [[SQL]] and [[Object Query Language]] were also influenced by the concept of records. These languages allow the programmer to store sets of data, which are essentially records, in tables.<ref>{{Cite web |title=What is a Relational Database (RDBMS)? |url=https://www.oracle.com/database/what-is-a-relational-database/ |access-date=February 28, 2022 |website=Oracle}}</ref> This data can then be retrieved using a [[Unique key|primary key]]. The tables themselves are also records which may have a [[foreign key]]: a key that references data in another table.&nbsp; &nbsp;