Talk:ADABAS

Some one please explain what the difference is between a record and a row in the context of an RDBMS? Same thing regarding a field and column. Years ago when RDBMS was all that was out there, the world still described these items as records and fields in my documentation. Row and column is representational description while record and field are functional descriptions. Heck, in the RDBMS spec, they real names are touple and attribute...so how are these really differentiators between Adabase and an RDBMS? If no one can clean that up to be more accurate, or explain to me how it is accurate as is, I'll try to come back later and remove the differences.

I agree. It would be more useful to point out that: it's index-dependent (unlike relational databases), i.e. you can't use a field as a search key if it's not indexed; its record structure supports 2 methods of de-normalisation, repeating groups and multiple record types per file.Philcha 22:17, 19 October 2007 (UTC)

To agree with the unsigned comments and with philcha: "field" and "column" can be alternative names for attributes in the relational model (see Date, *Database in Depth*, isbn 0596100124), and "record" and "row" can be alternative names for a tuple. Someone who actually understands databases needs to rewrite this (I know nothing about Adabas, so don't look at me).

Early database systems generally used the term 'record' in the COBOL sense: this is a hierarchic structure rather than a purely flat one. For example the field DATE-OF-BIRTH may include sub-fields YEAR-OF-BIRTH, MONTH-OF-BIRTH, DAY-OF-BIRTH; and fields may be repeated, including "repeating groups". The relational model's emphasis on "first normal form" was explicitly about getting rid of this internal structure within records. Mhkay (talk) 10:07, 20 December 2011 (UTC)

Dirty read??????

Nonsense. Adabas has locking mechanisms: lock individual records when reading them; lock a whole file so that e.g. other processes can't update the accounts while a trial balance is being run. I'm deleting "dirty read".Philcha 22:17, 19 October 2007 (UTC)

But are the locks properly serialized?

"Locks" with ADABAS is controlled by the application or utility, and in my experience (close to 30 concurrent years of ADABAS experience - mostly as an ADABAS DBA). whole file locks are rare (usually for maintenance by utility that requires exclusive file use) but some shops use them for application purposes. An application may "hold" a record for updating, and for efficiency sake for large batch transactional processing, keep 50 or 100 or some other number of records in "update hold" status before releasing them and continuing with such chunks of "update holds". The serialization is based on which inverted list makes sense for the application to use to process data in the most efficient manner. Occasionally there will be conflicts of multiple processes wanting to "lock" the same record, but failure can be avoiding if the applications are coded (or session parameters set) to wait and retry again.

I am curious what was said about dirty reads. One of my understandings how ADABAS is different than RDBMSs is when an update occurs in ADABAS, even before that update is committed with an ET command, the new value can be read by another process (assuming it does not want to update the record also). If for some reason the update is not committed, that update backs out and reverts to its original value, but the other process may have read it in its updated-but-not-committed state and done who-knows-what with it (anything but update it itself). RDBMSs keep re-do logs and rollback segments in order to allow records in this state to not have their new values read by concurrent processes so that if an update is not committed or intentionally rolled back, no trace of this temporary update could exist. Hence, this is where ADABAS gets known for allowing "dirty reads". --208.114.129.46 (talk) 02:20, 20 June 2017 (UTC)

Vague cheerleading

It's "one of the earliest" database products, it's "one of the world's fastest", it offers buzzwords and jargon, and it has unspecified "other leading edge capabilities". It's "very successful", provides "efficient access", and is "widely used". It slices, dices, takes out the trash, and leaves a mint on your pillow at the end of a hard day at the office. "It has been described as 'Post-relational' but 'Relational Like' in its characteristics", which is just an obfuscated way of saying that it is not a relational database, but that its degree of similarity to a releational database has been narrowed down to somewhere between 0% and 100%. Overall, this is a lot of cheerleading generally unfettered by actual facts, and the few facts which snuck in are all negative: no normalization, no SQL, no foreign keys. If this truly is one of the foundation database packages, it deserves a proper respectful historical treatment, with its limitations placed in the appropriate context of the 1970-ish Mainframe / Cobol subculture from which it came. 206.205.52.162 (talk) 00:57, 29 September 2012 (UTC)

“SQL … access and other leading edge capabilities”. SQL, roughly forty years old, is “leading edge”? Added Peacock tag to page. 206.205.52.162 (talk) 14:26, 23 October 2012 (UTC)

It IS one of the earliest DBMSs, together with IMS, at around 1969/1970. Of course those two had a prehistory. Around 1990 when I used ADABAS it was also fast (at the cost of some inflexibility and "repeating groups") but far slower than IMS. Ditlev Petersen (talk) 15:15, 7 July 2014 (UTC)

I just removed some of the cheerleading.–Jérôme (talk) 07:13, 8 August 2014 (UTC)

NATURAL

..or.. Natural, the 4GL: Separate or part of the ADABAS article?

A first cut, starting with a machine translation and lightly edited, is to be "part of." Pi314m (talk) 03:55, 22 August 2018 (UTC)