SCOUG-Programming Mailing List Archives

Date:	Fri, 24 Mar 2006 12:20:38 PST8
From:	"Gregory W. Smith" <gsmith@well.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Data Repository/Directory

Content Type: text/plain

"Lynn H. Maxson" wrote:
> Apparently some have not seen Uncle Lynn's design of the
> Data Repository/Directory. Let's rectify that.

...... Seven paragraphs omitted ......

> The directory then consists of two columns for the unique
> name, one 16-byte, fixed length character value, and the
> other a 4-byte binary value. In addition it contains two
> single-character columns, one to designate source type (D, C,
> or T) and the other to designate source structure (E or A).

I'm not sure, but I think you said:

CREATE DATABASE Repository;

CREATE TABLE Directory (
Name CHAR(16) NOT NULL,
UNIQUE Count INTEGER NOT NULL,
Type CHAR(1), /* D, C, or T */
Sturcture CHAR(1) /* E or A */
);

CREATE INDEX DirectoryKey ON Directory (
Name, Count
);

> A by-product of this lies in having a builtin versioning system
> down to the element level for all source types as versions
> occur in practice as homonyms. This exceeds the scope of
> any other existing versioning system in software AFAIK.
>
> Now having solved the problem of homonyms we can turn to
> that of synonyms (different name, same referent). That
> means we need an "alias" or "AKA" (Also Known As) table.
> We contruct this with a 4-column row consisting of a
> "designated" primary unique name and an "alternate" unique
> name with a row for all such associations.

CREATE TABLE Alias (
PrimaryName CHAR(16) NOT NULL,
AlternateName CHAR(16) NOT NULL,
Associations ??????
);

Now I am confused. You said four columns, but there were
only three nouns in the above paragraph that I could map
to columns in the table: 1) primary unique name, 2)
alternate unique name, and 3) associations. But the
term "associations" was used with the noun "row".
Maybe there is no "associations" column in the table??

...... Three paragraphs omitted ......

> As it turns out the three forms of analysis have only two
> visual possibilities. Classification has a two-level "unordered"
> hierarchy (container to contained) as given in any taxonomy
> textbook. Structure and operation offer an "ordered"
> hierarchy of the "contained" while retaining that of
> classification relative to container to contained.

Ordered???? I thought we were talking about a database here.
From what I remember from dbExpert, databases are UNORDERED
collections of data. When you select on a column entry, you
get all of the rows that match the column. But there is no
order to the rows that are returned. (This is similar to
retreiving the keys from a Python dictionary. The keys are
returned in an unordered list that has no relation to the
order in which the entries were put into the dictionary.)

> Thus we need only two additional tables, one for the common
> unordered container to contained enumeration; the other for
> the enumerated set of contained to contained (ordered)
> relationships. The "container" table like the "alias" table
> consists of 4 columns of two unique names with a row for
> each individual container to contained relationship. The
> "contained" table consists of 6 columns with a "unique" name
> composed of combining two-unique names of a
> "container-contained" with a "followed by" contained name.
> This allows for immediate loops (recursion), a contained name
> "followed by" itself as well as higher-level loops.

CREATE TABLE Container (
PrimaryName CHAR(16) NOT NULL,
AlternateName CHAR(16) NOT NULL,
??????
);

More confusion.... Two unique names <==> 4 columns. ??????

CREATE TABLE Contained (
UniqueName1 CHAR(16) NOT NULL,
UniqueName2 CHAR(16) NOT NULL,
ContainedName CHAR(16)
);

> Now let me see. That's four tables, one for a directory,
> another for an alias, and two for storing relationships. Now
> we need one for storing source statements which consists of
> two columns for the unique name, one for the statement
> length (possibly 16 bytes or less) and one variable-length for
> the statement (if greater than 16 bytes).

CREATE TABLE Statement (
StatementName CHAR(16) NOT NULL, ????? Two columns ?????
StatementLenght INTEGER,
Statement TEXT(1024)
);

> OK, that's five. Now we need one to store source data
> elements. Again with the same number of columns as for
> source statements.

CREATE TABLE Elements (
StatementName CHAR(16) NOT NULL, ????? Two columns ?????
StatementLenght INTEGER,
Statement BLOB(4096)
);

> OK, that's six...as promised. We might as well get generous
> here an include a seventh table for source text with the same
> number as for source statements. Or we could choose to use
> the same table as source statements for source text.

Seventh table??? Do you mean:

CREATE TABLE SeventhTable (
StatementName CHAR(16) NOT NULL, ????? Two columns ?????
StatementLenght INTEGER,
Statement TEXT(1024)
);

Is this a duplicate just for the sake of duplication?

> As source code and source text use (or should) the same data
> names in their references we have a means of combining their
> use when desired as in literate programming or separately as
> in code generation or user documentation. It gives us an
> easier means of synchronizing changes globally throughout all
> source code and text.
>
> Now we do have a "twitchy" part when it comes to data,
> specifically data assemblies (aggregates) which may be
> homogenous, e.g. arrays, or heterogenous, e.g. structure, or
> list or any combination thereof. This means additional
> columns for our data referent (object) table. That completes
> our data repository with directory.

Assemblies and aggregates????? Is this another departure from the
idea of a database by imposing an order on the data??

> Now save this so I don't have to repeat it in the future. I will
> just in case I do.
>
> That I think completely covers "The most powerful form of
> reuse is full reuse." Probably more so that has occurred to
> McConnell. Full reuse has to occur at the statement level. If
> it does, it automatically occurs at all higher assembly levels.
>
> Note that all assemblies occur as "lists" of names, whether
> source code, text, or data.

Unordered lists as in a database, or ordered lists as in a
data structure??????

For that matter, do we have to start from scratch for an SQL
engine written in SL/I. Or can we bootstrap with an open
source database such as Firebird, mSQL, PostrGress, or MySQL?

> Note that the software will supply
> names where the developer does not. The software will
> automatically do versioning without developer intervention in
> some instances, e.g. change to a source statement, and with it
> in other, e.g. when the developer wants to reflect a change
> globally.
>
> Now as to "Iteration and incrementalism in software
> development are essential" we will save for later discourse,
> although I did touch upon this in a previous response to Greg
> relative to immediate feedback "brainstorming" input.
--
Gregory W. Smith (WD9GAY) gsmith@well.com

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 24 | March | 2006 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.