📄 sdo.das.rel.examples.three-table.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html> <head> <title>Three-table example</title> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body><div style="text-align: center;"> <div class="prev" style="text-align: left; float: left;"><a href="sdo.das.rel.examples.html">Examples</a></div> <div class="next" style="text-align: right; float: right;"><a href="sdo.das.rel.limitations.html">Limitations</a></div> <div class="up"><a href="sdo.das.rel.examples.html">Examples</a></div> <div class="home"><a href="index.html">PHP Manual</a></div></div><hr /><div id="sdo.das.rel.examples.three-table" class="section"> <h2 class="title">Three-table example</h2> <p class="para"> The following examples use all three tables from the company database: the company, department, and employee tables. These introduce the final piece of function not exercised by the examples above: the non-containment reference <var class="varname">employee_of_the_month</var>. </p> <p class="para"> Like the examples above for company and department, this set of examples is intended to illustrate the full lifecycle of such a data graph. </p> <p class="para"> <div class="example"> <p><b>Example #1 One company, one department, one employee - Create</b></p> <div class="example-contents"><p> In this example a company is created containing one department and just one employee. Note that this example clears out all three tables at the start so that the exact results of the queries can be known. </p></div> <div class="example-contents"><p> Note how once the company, department and employee have been created, the <var class="varname">employee_of_the_month</var> property of the company can be made to point at the new employee. As this is a non-containment reference, this cannot be done until the employee object has been created within the graph. Non-containment references need to be managed carefully. For example if the employee were now deleted from under the department, it would not be correct to try to save the graph without first clearing or re-assigning the <var class="varname">employee_of_the_month</var> property. The closure rule for SDO data graphs requires that any object pointed at by a non-containment reference must also be reachable by containment relationships. </p></div> <div class="example-contents"><p> When it comes to inserting the graph into the database, the procedure is similar to the example of inserting the company and department, but <var class="varname">employee_of_the_month</var> introduces an extra complexity. The Relational DAS needs to insert the objects working down the tree formed by containment relationships, so company, then department, then employee. This is necessary so that it always has the auto-generated primary key of a parent on hand to include in a child row. But when the company row is inserted the employee who is employee of the month has not yet been inserted and the primary key is not known. The procedure is that after the employee record is inserted and its primary key known, a final step is performed in which the the company record is updated with the employee's primary key.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -