7 Replies Latest reply: Feb 16, 2013 5:24 PM by rgir RSS

    ADF Application Architecture

    rgir
      Hello,

      We have the following structure in our current database. It works just fine with Oracle forms application.
      We are in the initial stage of assessing ADF technology to migrate our application. Would the following database structure cause any problems with the ADF architecture? Some discussion threads I have read, point out to creating a materialized view to get around the problem. Is there any solution other than creating the materialized view? Looking forward to some expert recommendation.

      Table 1: (user table)
      User_key
      User_name

      Table 2:
      T2_Key
      T2_description
      T2_supervisor  Foreign key to user_key in Table 1
      T2_Assigned To  Foreign key to user_key in Table 1
      T2_approved By  Foreign key to user_key in Table 1
      T2_Completed By Foreign key to user_key in Table 1

      Edited by: user12168613 on Feb 13, 2013 1:25 PM
        • 1. Re: ADF Application Architecture
          Puthanampatti
          in ADF those table 2 foreign keys should be history columns.
          • 2. Re: ADF Application Architecture
            rgir
            We also have other user columns (owner, supervisor, approver) with foriegn keys to user table. That would not be part of the history table right?
            • 3. Re: ADF Application Architecture
              Puthanampatti
              yes
              • 4. Re: ADF Application Architecture
                Chris Muir-Oracle
                I think this discussion has already become confused, as I see a muddle of terms like "History columns" and "History table", the former an ADF concept, the later a database concept that Forms programmers are familiar with.

                So user12168613 let's go back to basics to understand your question.

                Firstly are you assessing ADF Business Components (ADF BC) to model your database tables? Your question generically talks about ADF but doesn't talk about what technology in ADF you're going to use to talk to the database. I'd suggest you should use ADF BC anyway if your team comes from a Forms background as it much more closely models the "Forms" way of thinking about database schemas than the other options such as that provided by EJB/JPA.

                Secondly why do you think that data model will not work in ADF? It's basically 2 tables involved with multiple FKs. For ADF BC it will not be a problem that there's 4 or more FKs back to the same table. What's your specific concern?

                Third, you refer to some forum posts talking about materialized views getting around a problem but you don't give us any hint to what the problem is or links to the posts, so we can't make any assessment on that comment for you.

                Finally have you thought about building a small ADF BC application to test this out yourself? The basics of ADF BC aren't that hard to learn.


                On a separate note it's worth updating your user ID to a real name, people on the forum appreciate talking to people, not 12168613.

                Regards,

                CM.
                • 5. Re: ADF Application Architecture
                  rgir
                  Chris,

                  You understood my questions and concerns exactly right. I appreciate your reply.

                  +"I'd suggest you should use ADF BC anyway if your team comes from a Forms background as it much more closely models the "Forms" way of thinking about database schemas than the other options such as that provided by EJB/JPA"+

                  --Yes we are planning to make use of ADF BC.  For our needs we need to display the names of these users in my .jsf page as supposed to the employee key, how do I do this? Currently we are using List of Values feature to display the user name in our POC app. Is this the correct approach? Or are there better approach?

                  Thank you.
                  • 6. Re: ADF Application Architecture
                    Chris Muir-Oracle
                    So what you're looking for is the equivalent in Oracle Forms where you create transient attributes that are populated by a post-update trigger based on some other field in the same row (in this your FK).

                    The equivalent to what you're attempting to achieve is the concept of "reference Entity Objects" in context of "View Objects with Joins". I recommend you read this chapter of the dev guide:

                    http://docs.oracle.com/cd/E35521_01/web.111230/e16182/bcquerying.htm#CEGEGHFB

                    Regards,

                    CM.
                    • 7. Re: ADF Application Architecture
                      rgir
                      Thank you very much.