|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
