Thread View: comp.sys.next.programmer
1 messages
1 total messages
Started by Art Isbell
Thu, 20 Aug 1992 19:24
Workarounds for DBKit's lack of support for compound relationships
Author: Art Isbell
Date: Thu, 20 Aug 1992 19:24
Date: Thu, 20 Aug 1992 19:24
40 lines
2899 bytes
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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads