Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!ucsfcgl!cca.ucsf.edu!labmed.ucsf.edu!brianc From: brianc@labmed.ucsf.edu (Brian Colfer) Newsgroups: comp.databases Subject: Re: Relational Database, with a Graphical type field Summary: Backend or Frontend? Message-ID: <3010@ucsfcca.ucsf.edu> Date: 2 Jul 90 19:41:23 GMT References: <1189@abcom.ATT.COM> <2873@tellab5.tellabs.com> <6207@tekgen.BV.TEK.COM> Sender: news@cca.ucsf.edu Organization: Dept. of Lab Medicine, University of California, San Francisco Lines: 76 In article <6207@tekgen.BV.TEK.COM> moiram@tekcae.CAX.TEK.COM (Moira Mallison) writes: >In article <2873@tellab5.tellabs.com> segel@Tellabs.COM (Mike Segel) writes: >>> 1) To be able to update the graphical entry of a tuple. >>> >> This gets to be tricky. It is not efficient to actually store >>the image as part of the tupple, instead actually store a pointer to >>the image. > >The problem with this is that you lose one of the important aspects >of the relational model, ie all the data resides in relations. >Now, some of the attributes hold data, and some hold pointers, and >it's up to the application to know what to do with the pointers. >I don't see this as a step forward. This is not true with all BLOB type systems. For example, with Informix-Online the engine treats it as if it were stored as part of the tuple so to the application it doesn't matter... I don't know the actual algorithms in OnLine ... I only know that it doesn't really matter since I can almost treat the engine as a black data box. > >>> 3) To be able to compare two fields of type "graphical". >>> This might be the hardest to define. A Griphics Guru >>> can be of help here. >>> >> This is definately application dependant. Who knows what you >>are storing in the BLOB. It could be a voice mail message, or some >>non-visual binary field. > >Advances in database technology will ideally make the DBMS smarter. >A BLOB does not. "All I've got is a whole bunch of bytes. I don't >know what to do with them. You better figure that out." The more >information that can be stored in the DBMS, the less effort will >be expended to build applications around it. What is stored in >the DBMS can be more easily shared and re-used. Non-numeric, Non-date/time, and non-ASCII data is not very well defined. It would be interesting to have a system which knew about all the common graphic types, GIF, TIFF, XBM, XWD, CGM, PostScript etc.... and all the important spreadsheet types ... and all the sound storage types ... and ... I think this is better handled in the front end ... there are some free utilities to deal with most of these types which can be integrated into the frontend. > >> .... Most applications which people say require >>an OODBMS can be done on a relational DBMS. >There is a lot that can be done with the relational model, but that >doesn't mean that the relational model can be all things to all >people. And some things that can be done with the relational model >cannot necessarily be done EASILY with the relational model. One >of the attractive aspects of the relational model is it's simplicity >and it's rigor. OODBMS may be the solution to some of the limitations of current relational database products. But I am not yet convinced. I don't see what advantage OODBMS has over relational databases. For example, one advantage proposed by some OODBMS advocates is in the ability to specify methods, data transform procedures, as a part of an objects definition. While not as abstract but certainly more clear one can define such transforms through a system table. The ability for the relational model to accomadate self reference, e.g. system tables, coupled with its inherent algebraic character makes it the most powerful strategy to deal with data. -- Brian Colfer | UC San Francisco |------------------------| | Dept. of Lab. Medicine | System Administrator, | brianc@labmed.ucsf.edu | S.F. CA, 94143-0134 USA | Programer/Analyst | BRIANC@UCSFCCA.BITNET | PH. (415) 476-2325 |------------------------|