🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.next.programmer
Article #1246

Workarounds for DBKit's lack of support for compound relationships

#1246
From: Art Isbell
Date: Thu, 20 Aug 1992 19:24
40 lines
2899 bytes

The 3.0 version of DBKit doesn't support relationships comprised of more than
2 attribute pairs.  DBModeler cannot be used to create relationships involving
more than 1 attribute pair.

So dbmodels are effectively limited to simple relationships involving only 1
attribute pair.  While compound relationships are not required to model data
using a relational database, their use simplifies schemas in many cases.  I am
working with a very large schema containing over 300 entities.  If the schema
is modified to eliminate compound relationships, the number of entities will
skyrocket, and attributes containing meaningless unique integers will have to
be added so that relationships can be built on these unique integers.  This
makes understanding and maintaining the schema much more difficult, and makes
ad hoc queries very difficult for users to implement.

So what are people doing to work around this serious DBKit limitation?  (NeXT
has acknowledged this limitation and plans to eliminate it, but not for the
initial 3.0 release).  Redesigning our schema doesn't seem like the best
approach.  We could create these relationships on the fly with "where" clauses,
but this is the old, code-intensive way of doing things that DBKit has been
designed to eliminate through the creation of a dbmodel incorporating these
relationships.  I guess we could use Sybase stored procedures to define these
relationships, although I'm not a Sybase expert at all and have been counting
on DBKit to eliminate the need for these rather low-level solutions.  How would
one integrate stored procedures with DBKit in a way that once compound
relationships are supported, minimal code changes would be required?  Or is
there some way to create entities in the dbmodel that don't exist in the real
data dictionary (a la views) that could be used to reduce all relationships
down to simple ones?  The dbmodel is a very rich model, but I haven't been able
to think of a way to use it to work around this limitation without adding a
bunch of client-side code.

Any thoughts or suggestions would be appreciated.
-- 

Art Isbell                                                      Cubic Solutions
NeXT Registered Developer #745         NeXT software development and consulting
Email: isbell@cats.UCSC.EDU                                Voice: (408)335-1154
USmail: 95018-9442                                           Fax: (408)335-2515
Technical Details
Message-ID: <170riaINNsf@darkstar.UCSC.EDU>
Path: arc1-ca.pugleaf.net!sparky!uunet!olivea!hal.com!darkstar.UCSC.EDU!cats.ucsc.edu!isbell

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!olivea!hal.com!darkstar.UCSC.EDU!cats.ucsc.edu!isbell
From: isbell@cats.ucsc.edu (Art Isbell)
Newsgroups: comp.sys.next.programmer
Subject: Workarounds for DBKit's lack of support for compound relationships
Keywords: DBKit
Message-ID: <170riaINNsf@darkstar.UCSC.EDU>
Date: 20 Aug 92 19:24:58 GMT
Organization: Cubic Solutions - NeXT software development and consulting
Lines: 40
NNTP-Posting-Host: am.ucsc.edu