home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / next / programm / 5718 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  2.8 KB
  1. Path: sparky!uunet!olivea!hal.com!darkstar.UCSC.EDU!cats.ucsc.edu!isbell
  2. From: isbell@cats.ucsc.edu (Art Isbell)
  3. Newsgroups: comp.sys.next.programmer
  4. Subject: Workarounds for DBKit's lack of support for compound relationships
  5. Keywords: DBKit
  6. Message-ID: <170riaINNsf@darkstar.UCSC.EDU>
  7. Date: 20 Aug 92 19:24:58 GMT
  8. Organization: Cubic Solutions - NeXT software development and consulting
  9. Lines: 40
  10. NNTP-Posting-Host: am.ucsc.edu
  11.  
  12.  
  13.  
  14. The 3.0 version of DBKit doesn't support relationships comprised of more than
  15. 2 attribute pairs.  DBModeler cannot be used to create relationships involving
  16. more than 1 attribute pair.
  17.  
  18. So dbmodels are effectively limited to simple relationships involving only 1
  19. attribute pair.  While compound relationships are not required to model data
  20. using a relational database, their use simplifies schemas in many cases.  I am
  21. working with a very large schema containing over 300 entities.  If the schema
  22. is modified to eliminate compound relationships, the number of entities will
  23. skyrocket, and attributes containing meaningless unique integers will have to
  24. be added so that relationships can be built on these unique integers.  This
  25. makes understanding and maintaining the schema much more difficult, and makes
  26. ad hoc queries very difficult for users to implement.
  27.  
  28. So what are people doing to work around this serious DBKit limitation?  (NeXT
  29. has acknowledged this limitation and plans to eliminate it, but not for the
  30. initial 3.0 release).  Redesigning our schema doesn't seem like the best
  31. approach.  We could create these relationships on the fly with "where" clauses,
  32. but this is the old, code-intensive way of doing things that DBKit has been
  33. designed to eliminate through the creation of a dbmodel incorporating these
  34. relationships.  I guess we could use Sybase stored procedures to define these
  35. relationships, although I'm not a Sybase expert at all and have been counting
  36. on DBKit to eliminate the need for these rather low-level solutions.  How would
  37. one integrate stored procedures with DBKit in a way that once compound
  38. relationships are supported, minimal code changes would be required?  Or is
  39. there some way to create entities in the dbmodel that don't exist in the real
  40. data dictionary (a la views) that could be used to reduce all relationships
  41. down to simple ones?  The dbmodel is a very rich model, but I haven't been able
  42. to think of a way to use it to work around this limitation without adding a
  43. bunch of client-side code.
  44.  
  45. Any thoughts or suggestions would be appreciated.
  46. -- 
  47.  
  48. Art Isbell                                                      Cubic Solutions
  49. NeXT Registered Developer #745         NeXT software development and consulting
  50. Email: isbell@cats.UCSC.EDU                                Voice: (408)335-1154
  51. USmail: 95018-9442                                           Fax: (408)335-2515
  52.