Database vs Data Structure?

[castironpi at gmail.com]

On Apr 19, 10:56 pm, Dennis Lee Bieber <wlfr... at ix.netcom.com> wrote:
> On Sat, 19 Apr 2008 11:27:20 -0700, Scott David Daniels
> <Scott.Dani... at Acm.Org> declaimed the following in comp.lang.python:
>
>         Hijacking as with the gmail kill filter I had to apply...
>
> > castiro... at gmail.com wrote:
> > > Are databases truly another language from Python, fundamentally?
>
>         Databases predate Python by decades... Though getting hardware fast
> enough to implement the current darling -- relational -- did take a few
> years.
>
>         In my college days, database textbooks introduced: Hierarchical (IBM
> IMS, I believe was the archetype used, though there were many others);
> DBTG (Data Base Task Group) Network (the DBMS on the Xerox Sigma-6 at my
> campus was a network model); and then gave Relational as an
> experimental/theoretical format. About two years after I graduated, the
> revised versions of the textbooks started with Relational, and then
> listed hierarchical and network as "historical" formats.
>
>         In hierarchical and network, one had to explicitly code for the way
> the data was stored... In simple form: hierarchical required one to
> access from a top-level record, which then had "fields" comprising
> related data (and could have multiple occurrences).
>
> Invoice:        has customer number, name, address, etc. and a "field" for
> line items... The line items were a subtree: item number, description,
> quantity, price, extended price...
>
>         Network extended the hierarchical model by allowing access to the
> "subtrees" from multiple different types of parent trees.
>
>         Relational started life as a theory of "how to view the data --
> independent of how it is stored" -- comprising relations (which are NOT
> the links between tables. In relational theory the terms equate as:
>
> Common/Lay                      Theory
> table                                   relation
> column                                  domain
> row/record                              tuple
>
> "relation" meant that all the data in each tuple was related to the
> others. The SQL "relationship operators" that are used to link separate
> tables are not where "relational database" comes from.
>
>         SQL started life as a query language -- also independent of how the
> data is stored. however, it fit into relational theory easily... Maybe
> because it sort of combines relational algebra and relational calculus.
>
>
>
> > Classic qualities for a database that don't normally apply to Python
> > (all properties of a "transaction" -- bundled set of changes):
>
>         Examples might have been useful <G>
>
> >      * Atomicity:
> >         A transaction either is fully applied or not applied at all.
>
>         Well... self-explanatory...
>
> >      * Consistency:
> >         Transactions applied to a database with invariants preserve
> >         those invariants (things like balance sheets totals).
>
>         One of the key ones...
>
>         update accounts set
>                 balance = balance - 100
>         where accountnum = "from account";
>         update accounts set
>                 balance = balance + 100
>         where accountnum = "to account";
>
>         A failure between the two update statements MUST ensure that no
> changes were made to the database... Otherwise, one would lose 100 into
> the vapor. (This example does link back to the "A" and is more on the
> user side -- the code needs to specify that both updates are part of the
> same transaction).
>
> >      * Isolation:
> >         Each transactions happens as if it were happening at its own
> >         moment in time -- tou don't worry about other transactions
> >         interleaved with your transaction.
>
>         Though how various RDBMs implement this feature gets confusing. One
> has everything from locking the entire database (basically meaning that
> "losing" transactions don't get applied at all and the code has to
> reexecute the transaction logic) down to those that can lock on
> individual records -- so overlapping transactions that don't need those
> records complete with no failures.
>
> >      * Durability:
> >         Once a transaction actually makes it into the database, it stays
> >         there and doesn't magically fail a long time later.
>
>         Assuming a disk failure is not "magic" and one doesn't have a recent
> backup <G>
>
> --
>         Wulfraed        Dennis Lee Bieber               KD6MOG
>         wlfr... at ix.netcom.com             wulfr... at bestiaria.com
>                 HTTP://wlfraed.home.netcom.com/
>         (Bestiaria Support Staff:               web-a... at bestiaria.com)
>                 HTTP://www.bestiaria.com/

I'm holding the premise that money can be made different ways, also
and as technique is scarce, and exploration in programming is a non-
negative utility.  I have a soft-coded script I can show, I'm just not
in the space program.