Just been watching this item
<https://www.youtube.com/watch?v=pWZBQMRmW7k> on the Asianometry
channel, informative as always, giving an intro to the Pick operating
system, one of only two that I know that were built from the bottom up
around a database.

I had a brief exposure to an actual Pick system in the mid-1980s,
mainly being used by a colleague at the software firm I was at. And
never saw it again after that. I understand it was a schemaless
database, with no record types or field types; every field value was a
string, and a field could have multiple subvalues, with special
delimiter characters reserved for marking the boundaries of subvalues,
values and records. I never found out what happened if these codes
appeared in the data; perhaps it just wasn?t allowed.

I remember ?Pick versus Unix? arguments going back and forth around
that time; the Pick fans argued that Unix was too heavyweight and
complicated for normal business use, while the Unix fans countered
that Pick was too specialized and limited in its functionality.

In the end, both products died, but the concepts of Unix live on in
Linux and the BSDs.

We all know that relational databases discourage repeating fields,
because they complicate data updates. How did Pick deal with this?
Perhaps it was handled because data updates could be done right at the
subvalue level, not being required to update an entire record at a
time. Am I right?

I think the video presenter gets one thing wrong: he talks about
?NoSQL? databases, when he means ?non-relational? databases. My
understanding of the ?NoSQL? movement is that even non-relational
DBMSes found it advantageous to adopt some form of SQL as their query
language. Thus, ?NoSQL? DBMSes don?t actually exist (in any
significant numbers) any more.

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/27/25 07:31, Ted Nolan <tednolan> wrote:

In article <10dn7dv$k0ut$1@dont-email.me>,
Lawrence D˜Oliveiro <ldo@nz.invalid> wrote:

Just been watching this item
<https://www.youtube.com/watch?v=pWZBQMRmW7k> on the Asianometry
channel, informative as always, giving an intro to the Pick operating
system, one of only two that I know that were built from the bottom up
around a database.

I had a brief exposure to an actual Pick system in the mid-1980s,
mainly being used by a colleague at the software firm I was at. And
never saw it again after that. I understand it was a schemaless
database, with no record types or field types; every field value was a
string, and a field could have multiple subvalues, with special
delimiter characters reserved for marking the boundaries of subvalues,
values and records. I never found out what happened if these codes
appeared in the data; perhaps it just wasnƒ??t allowed.

I remember ƒ??Pick versus Unixƒ?? arguments going back and forth around
that time; the Pick fans argued that Unix was too heavyweight and
complicated for normal business use, while the Unix fans countered
that Pick was too specialized and limited in its functionality.

In the end, both products died, but the concepts of Unix live on in
Linux and the BSDs.

We all know that relational databases discourage repeating fields,
because they complicate data updates. How did Pick deal with this?
Perhaps it was handled because data updates could be done right at the
subvalue level, not being required to update an entire record at a
time. Am I right?

I think the video presenter gets one thing wrong: he talks about
ƒ??NoSQLƒ?? databases, when he means ƒ??non-relationalƒ?? databases. My
understanding of the ƒ??NoSQLƒ?? movement is that even non-relational
DBMSes found it advantageous to adopt some form of SQL as their query
language. Thus, ƒ??NoSQLƒ?? DBMSes donƒ??t actually exist (in any
significant numbers) any more.

MUMPS is built around a non-sql database and is in wide use in banking and healthcare.

MCTS is built around a navigational database, but it was never
commercialized.


--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 27/10/2025 14:06, rbowman wrote:

On Mon, 27 Oct 2025 07:36:31 -0000 (UTC), Lawrence D?Oliveiro wrote:

I think the video presenter gets one thing wrong: he talks about ?NoSQL?
databases, when he means ?non-relational? databases. My understanding of
the ?NoSQL? movement is that even non-relational DBMSes found it
advantageous to adopt some form of SQL as their query language. Thus,
?NoSQL? DBMSes don?t actually exist (in any significant numbers) any
more.

https://towardsdatascience.com/8-examples-to-query-a-nosql-database- fc3dd1c9a8c/

It's possible but not necessary to put lipstick on a pig.

I understand that the IBM IMS DB was originally a non-sql database, or
Codasyl but it now does have an SQL interface.

Dave

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/27/25 10:02, David Wade wrote:

On 27/10/2025 14:06, rbowman wrote:

On Mon, 27 Oct 2025 07:36:31 -0000 (UTC), Lawrence D?Oliveiro wrote:

I think the video presenter gets one thing wrong: he talks about ?NoSQL? >>> databases, when he means ?non-relational? databases. My understanding of >>> the ?NoSQL? movement is that even non-relational DBMSes found it
advantageous to adopt some form of SQL as their query language. Thus,
?NoSQL? DBMSes don?t actually exist (in any significant numbers) any
more.

https://towardsdatascience.com/8-examples-to-query-a-nosql-database-
fc3dd1c9a8c/

It's possible but not necessary to put lipstick on a pig.

I understand that the IBM IMS DB was originally a non-sql database, or Codasyl but it now does have an SQL interface.

Dave

Hierarchical

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, 27 Oct 2025 17:02:40 +0000, David Wade wrote:

I understand that the IBM IMS DB was originally a non-sql database, or Codasyl but it now does have an SQL interface.

The three kinds of DBMSes I learned about were

* ?Hierarchical? (e.g. IMS), with (as I recall) links between parent
and child records.
* ?Network? aka ?CODASYL?, which is a generalization of
?hierarchical?, where the links can go in both directions.
* ?Relational? -- the kind which is most common today.

The thing with the first two kinds is that queries have to be done by
following links between records. Whereas relational databases can make
use of indexes if they?re present, else they fall back to exhaustive
searching.

You also hear about ?graph? databases nowadays, but I think they?re
just a rehash of the old network/CODASYL concept.

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 27 Oct 2025 14:31:37 GMT, Ted Nolan <tednolan> wrote:

MUMPS is built around a non-sql database ...

Would you call it a ?database?, or is it just ?ISAM files??

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, 27 Oct 2025 21:11:50 -0000 (UTC), I wrote:

The three kinds of DBMSes I learned about were

I suppose I should mention that X.500/LDAP uses a very different database structure: everything is (conceptually) in a single table, and the primary
key has a multilevel structure. There are ?schemas? that define the types
of records and the types of fields they can/must have, but a single record
can be an instance of multiple schemas -- it must conform to at least one. Every field in a record can only be there because a schema that it belongs
to allows it or requires it.

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 27.10.2025 22:11, Lawrence D?Oliveiro wrote:

On Mon, 27 Oct 2025 17:02:40 +0000, David Wade wrote:

I understand that the IBM IMS DB was originally a non-sql database, or
Codasyl but it now does have an SQL interface.

The three kinds of DBMSes I learned about were

* ?Hierarchical? (e.g. IMS), with (as I recall) links between parent
and child records.
* ?Network? aka ?CODASYL?, which is a generalization of
?hierarchical?, where the links can go in both directions.
* ?Relational? -- the kind which is most common today.

There have also been "Object-Oriented Databases". (We used them in
the 1990's, but I haven't followed how DBMSs evolved over time.)

Janis

[...]

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 27.10.2025 22:29, Lawrence D?Oliveiro wrote:

On Mon, 27 Oct 2025 21:11:50 -0000 (UTC), I wrote:

The three kinds of DBMSes I learned about were

I suppose I should mention that X.500/LDAP uses a very different database structure: everything is (conceptually) in a single table, and the primary key has a multilevel structure. [...]

Not quite. The table structure can be arbitrary, depending on any organizational sub-tree structure.

X.500 (or its massively stripped down LDAP) is not a DBMS as it is
usually defined. The standard defines services and protocols for a
possibly distributed cooperating system where each part may have
their own administrative responsibility and techniques. The actual
technical storage, typically the underlying "real" DBMS, may vary
between the distributed participants; you can consider them another
[technical] layer.

In the early 1990's I've actually written an X.500 based directory
for telephone data. It was an European project, and participating
members used their own DBMS'es for the actual data in the back-end,
while the X.500 "layer" served as standard for uniform access and interoperability. Our system had been used in two countries, some
other countries provided own X.500 systems and all were uniformly
accessed by all participants. The concrete data organization was
responsibility of the respective owners of the national sub-domains,
and it included not only the technical DB aspects but also schemas
(which needed not be conforming to any other country's schema, as
long as the [more generic] X.500 interface is correctly provided).

(LDAP is compared to X.500 an extremely reduced directory standard;
here we see often quite "local" data collections in systems or on
sites; these give more the impression of being a database.)

Janis


--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

rbowman <bowman@montana.com> writes:

I've never used that, only DB2. I have used Raima's db_Vista. It was a C
API and fast compared to big RDMS databases. For its day it was quite sophisticated. It arguably would have been better than Esri's choice of dBase for shapefiles.

when I transfered to SJR on west coast, I worked with Jim Gray and Vera
Watson on original SQL/relational, System/R ... and helped with transfer technology to Endicott ("under the radar" while company was involved
with the next great DBMS "EAGLE" ... to replace IMS). Then when "EAGLE" implodes there is request for how fast can System/R be ported to MVS,
which is eventually released as "DB2" (originally for decision/support
only) ... Jim refs:
https://jimgray.azurewebsites.net/ https://en.wikipedia.org/wiki/Jim_Gray_(computer_scientist)
and Vera Watson
https://en.wikipedia.org/wiki/Vera_Watson
... System/R
https://en.wikipedia.org/wiki/IBM_System_R

--
virtualization experience starting Jan1968, online at home since Mar1970

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/27/25 12:36 AM, Lawrence D?Oliveiro wrote:

Just been watching this item
<https://www.youtube.com/watch?v=pWZBQMRmW7k> on the Asianometry
channel, informative as always, giving an intro to the Pick operating
system, one of only two that I know that were built from the bottom up
around a database.

more than you ever wanted to know

https://www.pickwiki.org/index.php/Main_Page

https://reality.necsws.com/history/

https://github.com/Krowemoh/R83


--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)