You will have some performance problems if you take the
doc_type/doc_attribute approach, plus coding the application will not be
fun.

As another poster noted, flexfields are for Oracle Apps and they are just
the way Oracle apps tries to accommodate a limited amount of customization
to table structures. Essentially, a way to dynamically do COBOL record
types. A no-no for relational systems.

As for the one table approach, as another poster pointed out, disk is cheap,
especially if you're not storing any values in VARCHAR2 fields. Include a
document_type field in the table. To simplify programming, define a set of
views on top of the table which access just those columns applicable to a
particular document type. Since each view is just based on one table, it
will be transparently updateable without coding triggers. In addition, you
will have all the documents in one table for when you have to report on them
all or otherwise process them all. 

An alternative model which would also work is to have a subtype-supertype
set-up. That is, you have the columns common to all the tables in one
supertype table, and then join that to separate tables for the sub-types via
an arc implementation of the FKs. This gets you more efficient storage, an
easy way to process all of the document types, plus a pretty easy way to
process an individual document type, by joining the subtype-table with the
supertype-table.

Leslie

-----Original Message-----
Sent: Thursday, August 07, 2003 12:29 PM
To: Multiple recipients of list ORACLE-L


sorry, misunderstood

Invoices:
        - Origin
        - Form Template ID
        - AWB
        - Bill To Customer
        - Bill To Customer Name
        - Invoice #
        - Invoice date
        - customs Entry #
        - entry date
        - query handling (boolean)
        - cash application (boolean)
        - credit & collection (boolean)
        - text search (boolean)
        - shipment folder (boolean)

Customs Document:
        - AWB
        - Clearance #
        - Customs Entry #
        - Entry date
        - deferement #

Cash batches:
        - query handling (boolean)
        - cash application (boolean)
        - credit & collection (boolean)

So, you could see, we've more than 50 type of documents and in total those
have more than 70 different attributes (some are the same). There is not one
attribute that appears on every document type!!! I would create so 50 tables
(for each document type 1), but if someone has another suggestion, I would
like to do it in an other way.

-----Original Message-----
Sent: donderdag 7 augustus 2003 16:59
To: Multiple recipients of list ORACLE-L
attributes



Just one or two examples, please.



 

                      "Vernaillen Tim"

                      <tim.vernaillen          To:      Multiple recipients
of list ORACLE-L <[EMAIL PROTECTED]>                    
                      @xgs.be>                 cc:

                      Sent by:                 Subject: RE: Implementing
different document types with different attributes            
                      ml-errors

 

 

                      08/07/2003 10:44

                      AM

                      Please respond

                      to ORACLE-L

 

 





attribute is a specific part of an index-file, but those attributes are
different for all document types

-----Original Message-----
Sent: donderdag 7 augustus 2003 16:15
To: Multiple recipients of list ORACLE-L
attributes



What do you have as an example of an "attribute"?




                      "Vernaillen Tim"

                      <tim.vernaillen          To:      Multiple recipients
of list ORACLE-L <[EMAIL PROTECTED]>
                      @xgs.be>                 cc:

                      Sent by:                 Subject: Implementing
different document types with different attributes
                      ml-errors



                      08/07/2003 09:34

                      AM

                      Please respond

                      to ORACLE-L







Hello


I've an installation/implementation question!
We've to analyse 50 document types, in total those 50 has 70 different
attributes. We don't want to put all those document types into one table,
because more than the half (35) of the attributes are not always used for
each document type. This will have to much disk space for each record, if
most of the fields are just blank.


Has anyone suggestions how to build our table-structure?
I've heart something about FlexFields, what are they?
Takes every field diskspace, even if it's blank (null)?


Thanks in advance for the response!


Tim








--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Thomas Day
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the
message BODY, include a line containing: UNSUB ORACLE-L (or the name of
mailing list you want to be removed from).  You may also send the HELP
command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Vernaillen Tim
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the
message BODY, include a line containing: UNSUB ORACLE-L (or the name of
mailing list you want to be removed from).  You may also send the HELP
command for other information (like subscribing).





-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Thomas Day
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the
message BODY, include a line containing: UNSUB ORACLE-L (or the name of
mailing list you want to be removed from).  You may also send the HELP
command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Vernaillen Tim
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the
message BODY, include a line containing: UNSUB ORACLE-L (or the name of
mailing list you want to be removed from).  You may also send the HELP
command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Tierstein, Leslie
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to