Clever Geek Handbook

Create a view from another view

I didn't find anything on the internet or any other resource after searching, and I was wondering if you can shape the view by joining another view and other tables? Something similar to this, I believe the Server_ref.part_notification_view is a view connection.

Create View "PART_NOTIFICATION_VIEW" ("NOTIFICATION_IX", "PART_NBR", "MFG_CD", "PART_CLASS_CD", "LEADTIME", "BILLTO_CUST_NBR", "BILL_TO_ACCT_NM", "CUST_PART_NBR", "LAST_CUST_PO", "LAST_REQ_DT", "QTY_OPEN", "YEAR_USAGE", "AVAILABLE_SALE_STANDARD_QT", "ISSUE_DATE", "EFFECTIVE_DATE", "BRIEF_DESCRIPTION", "NOTIFICATION_TYPE", "ACTUAL_DOCUMENT_LINK", "AFFECTED_PARTS_LIST_DOC_LINK", "EMAIL_LINK", "FILE_FOLDER", "RECOMMENDED_REPLACEMENT", "PCN_TYPE", "IMPACT", "MANUFACTURER_NM", "LAST_BUY_DT", "LAST_SHIP_DT", "SALES_MIN_BUY_QTY", "SALES_MIN_PKG_QTY", "PART_DESC", "BOND_QOH", "BOND_QIT", "BRANCH_QOH", "BRANCH_QIT", "BOND_QTY", "BOND_PIPELINE", "BOND_OP", "BRAND_CD", "STATUS", "COMMENTS")
AS
  SELECT
    svr.notification_ix,
    svr.part_nbr,
    svr.mfg_cd,
    svr.part_class_cd,
    svr.leadtime,
    svr.billto_cust_nbr,
    svr.bill_to_acct_nm,
    svr.cust_part_nbr,
    svr.last_cust_po,
    svr.last_req_dt,
    svr.qty_open,
    svr.year_usage,
    svr.available_sale_standard_qt,
    svr.issue_date,
    svr.effective_date,
    svr.brief_description,
    svr.notification_type,
    svr.actual_document_link,
    svr.affected_parts_list_doc_link,
    svr.email_link,
    svr.file_folder,
    svr.recommended_replacement,
    svr.pcn_type,
    svr.impact,
    svr.manufacturer_nm,
    svr.last_buy_dt,
    svr.last_ship_dt,
    svr.sales_min_buy_qty,
    svr.sales_min_pkg_qty,
    svr.part_desc,
    NVL(svr.bond_qoh, 0)                                                                    AS bond_qoh,
    NVL(svr.bond_qit, 0)                                                                    AS bond_qit,
    NVL(svr.branch_qoh, 0)                                                                  AS branch_qoh,
    NVL(svr.branch_qit, 0)                                                                  AS branch_qit,
    NVL(svr.bond_qoh, 0)      + NVL(svr.bond_qit, 0) + NVL(svr.branch_qoh, 0) + NVL(svr.branch_qit, 0) AS bond_qty,
    NVL(svr.bond_pipeline, 0) + NVL(svr.po_qt, 0)                                                 AS bond_pipeline,
    svr.bond_op,
    svr.brand_cd,
    cs.status,
    cc.comments
  FROM pours_ref.part_notification_view svr
  JOIN css_status cs
  ON svr.part_nbr = cs.part_nbr
  AND svr.mfg_cd = cs.mfg_cd
  AND svr.billto_cust_nbr = cs.account
  JOIN css_comment cc
  ON svr.part_nbr = cc.part_nbr
  AND svr.mfg_cd = cc.mfg_cd
  AND svr.billto_cust_nbr = cc.account;
+3


source to share


2 answers


You probably have a view built on top of another view:

create table my_table (id number, name varchar2(20), address varchar2(30));

table MY_TABLE created.

create or replace view my_view_1 as
select id, name
from my_table;

view MY_VIEW_1 created.

create or replace view my_view_2 as
select mv1.id, mv1.name, mt.address
from my_view_1 mv1
join my_table mt on mt.id = mv1.id;

view MY_VIEW_2 created.

But you cannot reference anything in the underlying tables, including any fields that are not part of the view:



create or replace view my_view_3 as
select mv1.id, mv1.name, mv1.address
from my_view_1 mv1
join my_table mt on mt.id = mv1.id;

SQL Error: ORA-00904: "MV1"."ADDRESS": invalid identifier
00904. 00000 -  "%s: invalid identifier"

Base tables having the same columns are not a problem, and if you include more than that in the view, then you still need to alias them.

Sometimes, you can get performance issues, and it can be faster and more reliable - albeit possibly harder to maintain - if you create a new view over the same base tables and extend it to include the additional data you want.

+9


source


Long answer ...

This is one of the main characteristics of a relational database, which should not make logical difference between tables, query results, and views (which are simply stored queries). In fact, "relational" refers to rows of data that are accessible through any of them. http://en.wikipedia.org/wiki/Relation_%28database%29

Of course, the differences vary to varying degrees between different RDBMSs, especially when it comes to DDL commands (update, delete, insert), and they all impose restrictions on the types of objects that DDL can apply to.

Taking Oracle as an example, the system will allow views to be updated and deleted by stored keys, and inserts are possible, but rarely used in practice (instead of "trigger type", DDL is available for any kind).



So with all that in mind, you can run select:

  • Table
  • A set of concatenated tables
  • View
  • Request (usually referred to as a string)
  • Query joined to view and table
  • etc.

... and this choice can be encapsulated in a view definition.

Short answer: Yes

+5


source






More articles:


All Articles