roger@esquire.UUCP (Roger Reid) (01/09/88)
In article <2556@sfsup.UUCP> prj@sfsup.UUCP (P.Jayne) writes: >As for my other "mistakes" I will reply after a few more flames. The only >poster so far who knows of an actual complex database using "relational >technology" responded by email. My fellow loud-mouths are all using the net >and it's great! Keep them flames coming. We have what we believe to be one of the most complex relational database applications around running here on Britton Lee IDMs. They were done relational because there was no other way to do it that would work as well as we needed it to (network would have saddled us with all kinds of decisions far too early in design - We would have lost all flexibility and hence most of the usefulness of the system). Hierarchical couldn't have describe the thing usefully. The analytical flexibility we require can (at this time) only be satisfied by the relational model. (It also saves us all kinds of disk space due to as we have almost no redundant data). It runs on BLI hardware because of its complexity: there is no way a software based system could run the thing (not enough CPU cycles in a month). If we were to begin from scratch today it is quite possible that Sybase running on a backend Unix machine could take the place of the BLI - tho that has not been proven. It would cost my firm a significant portion of their billings to not use the relational model running on hardware simply because we could not keep track of the intense amount of detail necessary otherwise. If people are interested enough I might be able to post a more detailed article, after checking with my bosses that I am not giving away proprietary information. Send mail if you want to encourage me. As for other models, there are applications for which we use a locally developed single unique key, hash based set of functions. The key to this argument is to use the right tool for the right job. You don't use a $40000 piece of hardware or a $27000 piece of software to keep track of phone numbers, unless of course you are the West German phone company (which uses BLI's for directory assistance - an example of the largest (as opposed to the most complex) application of relational db).
pavlov@hscfvax.harvard.edu (G.Pavlov) (01/15/88)
In article <271@esquire.UUCP>, roger@esquire.UUCP (Roger Reid) writes: > In article <2556@sfsup.UUCP> prj@sfsup.UUCP (P.Jayne) writes: > >....... The only > >poster so far who knows of an actual complex database using "relational > >technology" responded by email. > > We have what we believe to be one of the most complex relational > database applications around running here on Britton Lee IDMs. > They were done relational because there was no other way to > do it that would work as well as we needed it to ..... We do not have the most complex application on a relational dbms, but it is substantial nevertheless: apx. 250 tables, the need for 80-100 logical views into various overlapping subsets of the tables, etc. We chose a relational dbms because it was our estimate that we would have to at least triple our programming staff otherwise (rather difficult on research budgets...). Why ? because the database has to also be highly dynamic, with 4-6 tables being added per month, 1-2 being retired, and new views of the data added at the rate of 2 per month. The relational dbms (which is not that important, but it happens to be com- mercial Ingres, which does give you QUEL) has allowed us to build a complete- ly data-independent set of core applications. As new tables are brought on- line, "administrative" tables are updated which describe specialized details about the tables, new logical views, etc, to the core applications. - thus, we have reduced structure modification to a data updating task, for most cases. Has this resulted in a "slower", less efficient system ? Maybe. But I do know that I can maintain highly acceptable throughput with additional hard- ware for a fraction of what the additional programming staff would cost. And, the programmers on board can concentrate on new applications instead of constantly rehashing the existing software base... greg pavlov, fstrf, amherst, ny.
UH2@PSUVM.BITNET (Lee Sailer) (01/15/88)
Another large scale system--I am told by a friend at USX (aka US Steel) that
their sales and marketing database is built using a relational system.
And isn't the New York Stock Exchange system relational?
roger@esquire.UUCP (Roger Reid) (01/16/88)
In article <29896UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: > >And isn't the New York Stock Exchange system relational? > I think that's true - in any case, many of the large brokerage houses here on Wall Street use BLI's for order systems - definatly non-trivial! Sybase is starting to make some inroads in that arena also. These are clear examples of where you NEED dedicated hardware (whether it's something like a BLI or something like Sybase on a backend processor) to do the work - it will just completely overwhelm the CPU to do this kind of crunching on the host machine. Roger Reid