Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!unisoft!hoptoad!rtech!markh From: markh@rtech.UUCP (Mark Hanner) Newsgroups: comp.databases Subject: Re: Database Machines Message-ID: <1042@rtech.UUCP> Date: Sun, 5-Jul-87 21:57:02 EDT Article-I.D.: rtech.1042 Posted: Sun Jul 5 21:57:02 1987 Date-Received: Tue, 7-Jul-87 01:33:52 EDT References: <2861@blia.BLI.COM> <2918@zen.berkeley.edu> <131@hippo.UUCP> <1026@sirius.UUCP> Reply-To: markh@rtech.UUCP (Mark Hanner) Organization: Relational Technology Inc, Alameda CA Lines: 80 In article <1026@sirius.UUCP> erics@cognos.UUCP (Eric Schurr) writes: >In article <131@hippo.UUCP> eric@hippo.UUCP (Eric Bergan) writes: >> This does, of course, have the problem of having to change the >>application(s) if you decide to move the data partitioning around. I >>like the Sybase approach to this - namely the transactions are stored >>in the database itself, rather than in the applications. While you still >>have to change the transactions if you change the schema, at least they >>are all in one place, and the applications themselves do not have >>to be rebuilt. you can go one step further and prevent having to alter your applications at all when redistributing data in a distributed database: have the query language use a distributed database catalog for defining "aliases" for the data locations. in ingres/star, there is a catalog which contains the "alias", and the associated node/database/table name information required to locate the data. thus, the following statement in an application: select * from staff; does not need to be changed only because the database administrator moved the data table: create temporary link oldstaff with node = corp, database = personnel, table = staff; create table staff as select * from oldstaff with node = newcorp, database = newpersonnel, table = staff; this brings up the general problem of maintaining large systems with hundreds or thousands of applications in various stages of the product life cycle. the more difficult it is for the system administrators to tune their systems (including load balancing, where distributed database provides some unique opportunities), the slower those systems will run. applications ideally should be built without respect to performance, but allow the system administrator to tune the performance of applications to match real system loads through techniques such as changing storage structures, adding indexes, moving data to different disks or nodes, etc. as networks get more complex and user demand more distributed data capability ("i know it's on the ibm mainframe, but i want to be able to use it with data on my department's vax"), giving this flexibility to the system administrator will be essential. >This statment intrigues me. I don't know anything about SyBase--do >they allow you to model/define *transactions*? Is this simply referring >to table (file/record) definintions or to the much broader--and more >complicated--notion of a transaction? What mechanism do they use to >define and report this? > yes, sybase does store transactions in the database: define transaction getpayroll as select s.name,s.salary*t.hours from staff s, timecard t where s.name = t.name and s.type="HOURLY"; and then use: exec sql getpayroll; in an application to run the query. the next step is to allow the definition of assertions (referential integrity) and asynchronus actions ("whenever reactor_coolant < 100 then update valves (coolant = coolant + 3)"). making these features work will depend greatly upon how much application development support is provided to help manage the proliferation of application objects stored in databases. the world is just now beginning to agree on sql as a standard for interaction with relational databases. but CASE and other major advances in application development technology are begging for standards in data dictionaries and display environments, where there are multitudes of feuding factions. this discussion may belong in comp.case, but a database system is useless unless its easy to build applications with it... cheers, mark -- markh@rtech.UUCP ucbvax!mtxinu!rtech!markh "someone else was using my login to express the above opinions..."