rowley@bath.cs.ucla.edu (Michael T Rowley) (06/12/91)
|> In article <1991May30.003525.21161@cs.ucla.edu>, I wrote: |> |> Hence, I think all objects in an OODB should be easily reachable |> from globally known objects. The most obvious candidates for |> such objects in an OODB would be collections representing the |> extents of the classes. |> In article <1991May31.175612.16655@objy.com> bobm@server.Berkeley.EDU (Bob Muller) writes: |> |> Mr. Rowley is correct in supposing that there must be globally known |> objects such as relations. You've got to use some kind of global name in |> the declaration of what you want. However, where he errs is in thinking that |> the only valid candidate for such names are classes or types. I think you may have misread the paragraph you were responding to. Obviously, I don't think that the only valid candidate for global names is class or type names. I also don't believe that the only collections which can be included in a query are class extents. But there are some good reasons why these should be available. The schemas for most OODB's are developed by application programmers. The structures and navigational paths he includes are those required by the application(s) being written. In the CAD world, there is often no need to consider anything other than the needs of the application programmer, since there is often no general purpose query language. If the database system is [also] to be used for management purposes, it is useful for it to provide a general purpose query language. In order for it to be general, it must be possible to pose queries which do not naturally fit within the navigational structure designed by the application programmer. In the extreme, it can be argued that it is sufficient for the query language to be designed as if the query was to iterate over every object in the database, checking each object to see if it meets the conditions given in the query. However, this is inconvenient since most of the objects will be of the wrong type to even check the conditions (they don't respond to the messages used by the condition). A more general approach is to design the query language so that the type is specified first, then only objects of this type are checked against the query conditions. Thus, I argue that an OODBMS which can access all instances of each object type can provide a more general and easy to use query language. Michael Rowley