home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / database / informix / 1602 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  3.1 KB
  1. Path: sparky!uunet!gatech!pirates!emory!emory.mathcs.emory.edu
  2. From: widener!obelix.informix.com!johnl@emory.mathcs.emory.edu (Jonathan Leffler)
  3. Newsgroups: comp.databases.informix
  4. Subject: Re:  dbschema and documenting tables/columns
  5. Message-ID: <9224@emory.mathcs.emory.edu>
  6. Date: 24 Jul 92 09:29:12 GMT
  7. Sender: walt@mathcs.emory.edu
  8. Reply-To: widener!obelix.informix.com!johnl@emory.mathcs.emory.edu (Jonathan Leffler)
  9. Lines: 48
  10. X-Informix-List-ID: <list.1337>
  11.  
  12. >From: uunet!col.hp.com!judym (Judy Miller)
  13. >Subject: dbschema and documenting tables/columns
  14. >Date: 23 Jul 92 16:49:57 GMT
  15. >X-Informix-List-Id: <news.1574>
  16. >
  17. >I need suggestions for documenting an Informix database I support.  It
  18. >has been modified greatly since it was first created.  I used the dbschema
  19. >utility to create a fresh schema.  The problem is the original sql files
  20. >contained lots of valuable documentation.
  21. >
  22. >Is Informix self-documenting (meaning you can add descriptions somewhere
  23. >in the database), or can someone suggest a method where I can make it
  24. >self-documenting?  (or I'll invent my own...)
  25. >
  26. >I'd like the descriptive info to be part of the database, not a separate
  27. >file that must be maintained.
  28.  
  29. DB2 has a comments column in its equivalent of Systables and Syscolumns,
  30. which can be used to store the extra information -- Informix does not.
  31. This means that if you are going to keep the comments in the database, you
  32. will either have to play with the system catalogue (and you'll be all on
  33. your own when everything falls into a heap around your feet -- it would NOT
  34. be supported), or you provide your own data dictionary tables, or you buy a
  35. third party data dictionary system (there must be some out there, but I
  36. don't have anything in mind).
  37.  
  38. If you decide to write your own data dictionary, bear in mind that tables
  39. can be altered, and that Systables.Tabid usually changes when you alter a
  40. table.  This makes it unsuitable for use as the primary key of your data
  41. dictionary table description table.  You will probably end up defining your
  42. own equivalent of Tabid, with table name as an alternative key, and the
  43. actual tabid as a foreign key.  Similarly, columns can be moved around in
  44. the table, so the Colno attribute is not necessarily as useful as it could
  45. be.  And both table names and column names can be altered.  The point I'm
  46. making is that the system catalogue can change without your data dictionary
  47. being aware of the change, and if your dictionary is too closely tied in to
  48. the key structures in the system catalogue, you will get erroneous
  49. information out of your data dictionary after the database is changed.
  50.  
  51. Which version of Informix are you using?  If you are using Version 5.00,
  52. you can declare PRIMARY KEYs, FOREIGN KEYs and CHECK constraints.  These
  53. are often part of the information which would exist as comments, but they
  54. can be documented in the database explicitly, which is a step in the right
  55. direction.  It does not allow you to document the purpose of a table or
  56. column, though, so you still need some data dictionary support.
  57.  
  58. Yours,
  59. Jonathan Leffler (johnl@obelix.informix.com) #include <disclaimer.h>
  60.