categories of data

Which option is best for displaying categories of data in a database: record type objects, record view interfaces.......

  Discussion posts and replies are publicly visible

Parents
  • 0
    Certified Lead Developer

    A typical design pattern I've seen many times is for CDTs used in processing, (process variables) to match data tables for writing, and for Record List Items (The smaller part shown for each record in your list of records) a special CDT is purpose built and associated with a database View, and a database View and matching CDT for the Record Summary (The more detailed stuff you see when you click on one record in the list).

    So in general, Records often coincide with database Views, process variables often coincide with database tables.  Stored Procedures and Stored Functions don't really have an association with Appian, though the output of a Stored Function could be a CDT, PV, or Record.

    Another good design pattern that I saw was to associate Reference tables with Constants.  For instance, you could store a list of U.S. States on a DB reference table and as a constant in Appian.  Why both?  Say a new requirement comes down the pipeline that says Puerto Rico has to be included in the list.  You write a SQL script to add Puerto Rico, and an automated process that runs on an off-hours schedule reads the new data, registers the change, and updates the constant only when the table changes.  Your users only poll from the constant and never tie up DB connections.  And someone looking in your data alone can still do joins and read out "Puerto Rico" in their results without having to go to Appian.

Reply
  • 0
    Certified Lead Developer

    A typical design pattern I've seen many times is for CDTs used in processing, (process variables) to match data tables for writing, and for Record List Items (The smaller part shown for each record in your list of records) a special CDT is purpose built and associated with a database View, and a database View and matching CDT for the Record Summary (The more detailed stuff you see when you click on one record in the list).

    So in general, Records often coincide with database Views, process variables often coincide with database tables.  Stored Procedures and Stored Functions don't really have an association with Appian, though the output of a Stored Function could be a CDT, PV, or Record.

    Another good design pattern that I saw was to associate Reference tables with Constants.  For instance, you could store a list of U.S. States on a DB reference table and as a constant in Appian.  Why both?  Say a new requirement comes down the pipeline that says Puerto Rico has to be included in the list.  You write a SQL script to add Puerto Rico, and an automated process that runs on an off-hours schedule reads the new data, registers the change, and updates the constant only when the table changes.  Your users only poll from the constant and never tie up DB connections.  And someone looking in your data alone can still do joins and read out "Puerto Rico" in their results without having to go to Appian.

Children
No Data