home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / database / ingres / 1027 < prev    next >
Encoding:
Text File  |  1992-07-29  |  6.4 KB  |  169 lines
  1. Newsgroups: comp.databases.ingres
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!sdd.hp.com!ux1.cso.uiuc.edu!uchinews!gsbacd.uchicago.edu!cs_mj
  3. From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
  4. Subject: Re: Naming conventions
  5. Message-ID: <1992Jul29.160529.1@gsbacd.uchicago.edu>
  6. Lines: 157
  7. Sender: news@uchinews.uchicago.edu (News System)
  8. Organization:     
  9. References: <1992Jul27.145402.11313@schaefer.math.wisc.edu>
  10. Date: Wed, 29 Jul 1992 22:05:29 GMT
  11.  
  12. In article <1992Jul27.145402.11313@schaefer.math.wisc.edu>,
  13. horn@schaefer.math.wisc.edu (Jeffrey Horn) writes:
  14. > How do YOU name database objects and ingres application objects.  I am
  15. > interested in naming conventions for:
  16. >
  17. >     Databases
  18. >     Tables
  19. >     Forms
  20. >     Frames
  21. >     4gl procedures
  22. >     SQL Procedures
  23. >     Rules
  24. >     Database Events
  25.  
  26. Here's a summary of some of our naming conventions.
  27.  
  28. Databases
  29.  
  30. For system XXX we usually set up three database with names:
  31.  
  32.     XXXprod    Production database. Minimal frontend objects,  usually
  33.         just reports. (We don't use QBF for production work
  34.         so no forms or joindefs are stored in the production
  35.         database.)
  36.  
  37.     XXXtest    Periodic snapshot of the production database
  38.         for testing new applications, different tables designs,
  39.         etc.
  40.  
  41.     XXXdb    Development database, usually with a small subset of real
  42.         data.  ABF work takes place here.
  43.  
  44. Database Areas
  45.  
  46. For database areas we use VMS rooted logicals:
  47.  
  48.     $ define/translation=concealed area_name device:[dir.]
  49.  
  50. We define a complete set of logicals for each and every database, even
  51. if two database physically share a disk.   We create separate areas for
  52. data, checkpoints, journals, and dump files.  This gives us complete
  53. flexibility to relocate any part of a single database to other disks
  54. with VMS BACKUP (to move the files) and logical name redefinition (to
  55. tell INGRES where to find the relocated files) without interfering with
  56. any other database.  The database locations defined in ACCESSDB remain
  57. unchanged.
  58.  
  59. Our conventions for these area logical names are:
  60.  
  61.     default database area    DB_dbname
  62.     extended areas        DB_dbname_1, DB_dbname_2, ...
  63.     checkpoint area        CKP_dbname
  64.     journal area        JNL_dbname
  65.     dump area        DMP_dbname
  66.  
  67. Does anyone know how to do this Unix?  Is it necessary, in view of soft
  68. links?  In VMS, our scheme is _very_ useful in making all databases
  69. completely independent of one another.  It's very easy to move all or
  70. part of a database when we have to shuffle things around because a disk
  71. fills up or breaks.
  72.  
  73. Tables
  74.  
  75. Our databases (academic administration) tend to have subdomains (e.g.,
  76. Admissions, Dean of Students, Alumni).   Some tables are common to all
  77. subdomains (e.g., basic biographic information, code constraint tables)
  78. and some are specific to subdomains (e.g., application data, registered
  79. courses,  alumni donations).  We use a short prefix for each table to
  80. identify it as common (global in our terminology) or subdomain specific.
  81. Our table codes are
  82.  
  83.     GL_    Global (common)
  84.     AC_    Academic Servics
  85.     AD_    Admissions
  86.     DV_    Alumni/Development
  87.     PO_    Placement Office
  88.     RG_    Dean of Students/Registrar
  89.  
  90. You get the idea.  Since version 6 we've tended toward longer table
  91. names, with underscores to separate words.  Our table names are always
  92. singular, so that the name defines what one row from the table is, not
  93. the whole collection.  For example, the table that holds persons is
  94. "gl_person", not "gl_persons".
  95.  
  96. For secondary indexes, the convention is "x_tname_cname", where "tname"
  97. is the name of the table and "cname" is the name of the first column in
  98. the index.
  99.  
  100. For views, we use exactly the same conventions as for base tables.  SQL
  101. is supposed to treat tables and views the same, so we name them the
  102. same.
  103.  
  104. The convention makes it easy to identify what a table is for and which
  105. system it belongs to.  
  106.  
  107. Forms
  108.  
  109. We use the same subdomain prefixes as for our tables, and add a suffix
  110. to every form name, "_f".   The reason for the suffix is that we write a
  111. fair number of frames in embedded SQL/C (though as 4GL gets better that
  112. trend is changing), and we need two distinct names, one for the C
  113. procedure and one for the form (otherwise you get a linker name conflict
  114. between the procedure and the compiled form).
  115.  
  116.     c procedure: xx_frame_name
  117.     form name:   xx_form_name_f
  118.  
  119. This convention is not so binding for 4GL frames, where the framename
  120. and formname can be identical.  The convention makes it easy to find the
  121. form for a given frame, and, conversely to figure out what source code
  122. goes with a given form.
  123.  
  124. Within forms, we have some conventions for the names of table fields and
  125. simple fields.  All table field names look like "person_tf", where the
  126. name indicates what a row in the table field represents, and the "_tf"
  127. suffix makes it easy to see what the object is in source code.  Simple
  128. fields usually have the same name as the column in the database that
  129. they correspond to.  We also have simple fields like "person_tfn", which
  130. displays to the user how many rows there are in the corresponding table
  131. field.
  132.  
  133. 4GL frames, 4GL procedures, 3GL procedures.
  134.  
  135. We use a similar subdomain prefix naming convention for all our
  136. procedures (all flavors).  In addition to the administrative subdomains
  137. listed above we introduce additional prefixes as needed to identify
  138. significant application subcomponents or general utility libraries.
  139.  
  140.     DV_    Alumni/Development System
  141.     GF_    Gift Entry Subcomponent
  142.     PO_    Placement System
  143.     PB_    Student Interview Bidding Subcomponent
  144.     TX_    Transaction and Error Handling Utility Library
  145.     FRS_    FRS Utility Library
  146.     STR_    String Utility Library
  147.  
  148. Local procdures (4GL local procedures and C static functions) are given
  149. a prefix specific to the module they are in, but this is not as
  150. critical.
  151.  
  152. Rules and SQL Procedures
  153.  
  154. We don't actually have a lot of database procedures or rules, but I have
  155. thought about this and decided on this convention: "tname_oper_rule" for
  156. the rule, and "tname_oper_proc" for the procedure that the rule invokes. 
  157. "tname" is the name of the table; "oper" is the update operation
  158. (insert, update, or delete); and "rule" is fixed text that indicates the
  159. type of the database object.  This makes it really easy to do things in
  160. the SQL terminal monitor such as "help rule tname*", so you can see all
  161. of the rules that are defined on a table.
  162.  
  163. --Mark Jaeger                internet: cs_mj@gsbvax.uchicago.edu
  164. --Paul Ford                internet: cs_paul@gsbvax.uchicago.edu
  165. Graduate School of Business        yellnet:  (312) 702-7411
  166. University of Chicago            faxnet:   (312) 702-0233
  167. Disclaimer: Our opinions are our own and not those of my employer.
  168.  
  169.