Re: Where do constraints go?

Not sure I have a problem, more like some interesting observations. It
bothers me, however, that the sizes of referential constraints (and
probably unique key constraints over and above a primary key constraint)
are not reported in the total member size. (heh heh, I know, put in a DCR   ;-)

I'm also curious which of these constraints will be considered for use in
SQL optimization. All but check constraints are described as having an
access path.

As always, could do this myself (am looking at some of it as I write). Just
wondering is others have comments or more insight.

At 10:58 AM 4/29/02 -0500, you wrote:
>This is a multipart message in MIME format.
>--
>[ Picked text/plain from multipart/alternative ]
>What problem are you trying to solve?  Are you trying to determine if
>adding a constraint significantly adds to an object size?  If so, is this
>size based on the number of records?
>
>I guess doing a DSPOBJD of an small file before and after the constraint
>was added should tell you if the size is significant.  Then doing the same
>on a large file should tell you if it is dependent on the number of rows.
>
>Rob Berendt
>--
>"They that can give up essential liberty to obtain a little temporary
>safety deserve neither liberty nor safety."
>Benjamin Franklin
>
>
>
>
>Vernon Hamberg <vhamberg@attbi.com>
>Sent by: midrange-l-admin@midrange.com
>04/29/2002 10:40 AM
>Please respond to midrange-l
>
>
>         To:     midrange-l@midrange.com
>         cc:
>         Fax to:
>         Subject:        Where do constraints go?
>
>
>Am trying to figure out how much space is used when you put referential
>and
>check constraints on a file. It appears that referential constraints
>actually take up space, and this is reported in the member description of
>DSPFD. However, it is not part of the member size reported at the bottom.
>That value seems to be the sum of the data space size and the primary or
>PF
>key index size. You can see the file's true size in DSPOBJD.
>
>Not sure what I'm asking, if anything. Just interesting.
>
>BTW, the size information reported in DSPFD TYPE(*ALL) OUTPUT(*) or
>OUTPUT(*PRINT) does not show up in, say, TYPE(*MBR), where it is displayed
>in TYPE(*ALL). So there's no outfile support for this information.
>
>Vern Hamberg
>
>Would you like to see a challenging little arithmetic puzzle
>that might get you or your kids or grandkids more interested
>in math? Go to <http://cgi.wff-n-proof.com/MSQ-Ind/I-1E.htm>
>
>Sillygism--
>
>Something is better than nothing.
>Nothing is better than a ham sandwich.
>Ergo
>Something is better than a ham sandwich.
>
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
>list
>To post a message email: MIDRANGE-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>or email: MIDRANGE-L-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.
>
>
>
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>To post a message email: MIDRANGE-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>or email: MIDRANGE-L-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.