On Apr 19, 10:56 pm, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > On Sat, 19 Apr 2008 11:27:20 -0700, Scott David Daniels > <[EMAIL PROTECTED]> declaimed the following in comp.lang.python: > > Hijacking as with the gmail kill filter I had to apply... > > > [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] [EMAIL PROTECTED] > HTTP://wlfraed.home.netcom.com/ > (Bestiaria Support Staff: [EMAIL PROTECTED]) > 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. -- http://mail.python.org/mailman/listinfo/python-list
