|
|
|
| Authored by: jesse on Monday, May 21 2012 @ 08:47 AM EDT |
The origin of relational databases on UNIX was from the use of several common
utilities - sort, cut, comm, awk.
I have used these to create a "relational" database used for a cross
reference tool when working on some rather large FORTRAN programs. The tool
allowed for a "called by" report and a "calls" report for
FORTRAN programs. The data load would require all subroutines of a FORTRAN
program to be in separate files (named the same as the subroutine). The scanner
would then identify the file-calls lists from all of the files, sort it to
eliminate the duplicates. The report generation would then output a formatted
report (the calls list in a pretty print list) or resort them to generate a
"called-file" list which would be put in another report.
Saved several days of manual work per program.
Ingress was the first relational database for mini-computers, then used (with a
lot of modifications - this from a rather fuzzy memory) for the first Oracle
database using SEQUEL (later SQL).
Relational algebra can be implemented in many different ways. SQL, being a not
very good one (it doesn't follow the rules entirely). Personally, I always
preferred QUEL as it was more regular, and easier to understand. But then, it
was also the first one I learned. You could implement your database
backup/restore (import/export) in QUEL, but you cannot do that with SQL.
[ Reply to This | Parent | # ]
|
| |
| Authored by: Wol on Monday, May 21 2012 @ 03:54 PM EDT |
SQL does not always imply a relational *engine* - indeed pretty much every
Pick-style database I know of has a SQL query engine.
SQL (Structured Query Language) assumes a normalised database. A relational
database is a First Normal Form database, and SQL is optimised to query that.
Pick does not enforce normal form, but I would have no problems calling any Pick
programmer who did not normalise an idiot. But done properly, a Pick database is
Non First Normal Form, often referred to as NF2.
So done properly, a Pick FILE is equivalent to a relational *view*, but without
all the duplicates and foreign keys and other cruft that gets in the way. If you
do an EAR analysis (Entity Attribute Relationship) then each Pick FILE should be
equivalent to a class, storing one instance of an entity per RECORD. And because
the entity should have been normalised, converting a Pick RECORD into a
relational view and rows is a trivial mathematical transform. And can probably
be done far faster than it takes to read all those rows from a truly relational
database. (trivial as in easy, not the mathematical "follows
inevitably").
So SQL, expecting a first normal form data structure, can be fed such from Pick
dead easy - unless the programmer didn't analyse things properly (which happens
too often for comfort :-(
Cheers,
Wol[ Reply to This | Parent | # ]
|
|
|
|
|
