I have a table of parent-child relationships:
CREATE TABLE item_parent(item_hash, parent_hash);
CREATE UNIQUE INDEX item_parent_unique ON item_parent(item_hash, parent_hash);
CREATE VIEW item_timestamp AS SELECT item_hash, item_timestamp FROM [...]
I would like to create a view which aggregates these into the following columns:
item_hash (from the table)
child_count (recursively summarized)
newest_timestamp (joined from item_timestamp, most recent timestamp of all the items which are in the tree)
I understand I'm supposed to do something with WITH RECURSIVE, but having trouble figuring out the syntax. I've looked around SO already.
Related
I have three objects: Master, Join, and Item. Join has a Master-Detail relationship to Master called Master__c and a lookup relationship to Item called Item__c.
Given a list of Master Ids, I want all of the Master records along with the names of the related Item records through Join. How do I do this?
If I understand the objects and relationships you described correctly,
Master is the parent object and can have zero or more Join records.
Join is a child of Master and can have zero or 1 reference to an Item.
If so, you can use a SOQL query like this:
select id, name, (select name, item__r.name from Master__r) from Master where id in ()
The question is about SQLite.
Suppose I have a view which is a result of a join of multiple tables, the tables are linked with foreign key constraints and all indexes are in place, and a select statement against such a view is executed and it uses a where condition which selects only a subset of the available rows. For each statement, the view must be 'materialized' (I don't know what the real word is), but is it materialized fully for all rows and the filtering from the select takes place then, or is the view materialized in a 'smart' way in which it already pre-filters the data somehow? Does it even matter? How does this work?
When you are querying a view like this:
SELECT ...
FROM MyView
WHERE ...
then the view gets merged as a subquery, like this:
SELECT ...
FROM (SELECT ...
FROM ...
WHERE ...)
WHERE ...
Futher processing is the same, whether the subquery originated from a view or was written explicitly in the query.
If possible, SQLite tries to flatten the subquery so that the end result is a single, simple query with all the joins and WHERE conditions merged together.
If that is not possible, SQLite tries to implement the subquery as a coroutine, i.e., it executes the inner query until it gets one row, and then applies any processing of the outer query to that row; then outputs the result, if any; then repeats.
Only if the inner query must compute all rows before returning the first one (for example, when using an ORDER BY that cannot be flattened), then using a coroutine is not possible, and the inner query is actually materialized into a temporary table.
I've been thrown quite the scenario today. Essentially, I have one table (ProjTransPosting) that houses records, and that table relates to a number of similarly structured tables (ProjCostTrans, ProjRevenueTrans, etc). They relate by TransId, but each TransId will relate to only one of the number of child tables (meaning if a TransId of 137 exists in ProjCostTrans, there cannot be a TransId of 137 in ProjRevenueTrans). The schemas of the children tables are identical.
So, my original thought was to create a Map and create the mappings from the various children tables. And then I would use this Map as a datasource in the form so everything can show up in one column. I created all the relationships between the Map and the children table along with the relation to the parent table. I put Map in the form as a datasource and this caused a blank Grid, although I don't know why. Is it the case that the Map object can only by of one table type at any given time? I thought the purpose of this was that it could be universal and act as a buffer to many record types. I'd like to pursue this route as this definitely would achieve what I'm looking for.
In failing this I was forced to arrange my Data Source to perform something like this: SELECT ProjTransPosting LEFT JOIN ProjCostTrans LEFT JOIN ProjRevenueTrans ... The problem with this is, each child table I add-on, it's creating additional columns, and the values of the other columns are all NULL (blank in AX). So I have something like this:
Parent.TransId ChildA.Field ChildB.Field ChildC.Field
1 NULL 1256 NULL
2 1395 NULL NULL
3 NULL 4762 NULL
4 NULL NULL 1256
Normally, the user would deal with the annoyance of having the extra columns show up, but they want to also be able to filter on the fields in all the children tables. My example above, they want to be able to filter "1256" and the results would return TransIds 1 and 4, but obviously since the values in this case are spread out in multiple columns, this cannot be done by the user.
Ideally the Map would "combine" these columns into one and then the user could filter easily on it. Any ideas on how to proceed with this?
Try creating a union query and then a view based on that query.
Maps are supposed to be used only in X++, and not as data sources in forms.
This sounds like the exact purpose of table inheritance in AX 2012.
http://msdn.microsoft.com/en-us/library/gg881053.aspx
When to use:
http://msdn.microsoft.com/en-us/library/gg843731.aspx
EDIT: Adding my comments here to make this a more full answer.
Let's say you have three tables TabPet, TabPetCat, TabPetDog, where TabPet is the supertype table and the others are decedents.
If you insert two records each into TabPetCat and TabPetDog (4 total), they will all have unique recIds. Let's say TabPetCat gets 5637144580 and 5637144581. TabPetDog gets 5637144582, and 5637144583.
If you open TabPet, you will see 5637144580, 5637144581, 5637144582, and 5637144583.
So what you would do is make your table ProjTransPosting the supertype and then ProjCostTrans, ProjRevenueTrans, etc descendant tables. Unless transId is really necessary, you could just get rid of it and only use RecId.
I need to assign one of multiple parent types to a single child item. The problem I encounter is that in an Access 2010 web database I cannot create a Union query to bring all the potential parents (from multiple tables) into a single drop down / listbox.
I'm a bit green to all this and could be going about it completely wrong. I'm very open to suggestions. Here is my example:
Contracts are the parent of Subcontracts.
Both Contracts and Subcontracts have a Statement of Work (SoW).
Contracts and Subcontracts can both be direct parents of a SoW.
Each SoW will have only one parent
SoWs are split into paragraphs (not overly consequential)
With a union query I would build the database this way:
Contracts table
Subcontracts table
Union table for contracts and subcontracts
Lookup to union table from SoW table in order to select either a contract or a subcontract as parent from a single data source.
The problem here is that I cannot create a union query in a web database.
My only other thought is to construct the database in this fashion:
Contracts table
Subcontracts table
Contracts SoW table
Subcontracts SoW table
This design (using two tables) might work more effectively for data entry as there could be issues with subforms when attempting to use a union table. I'm not sure as I haven't yet tried. With this method, the Access report should be able to bind the subcontract to the parent contract and display all data in a detail section. However, this design still means that I will use two separate tables to house identical data.
I would put the two contract tables together into one table that would look something like this:
CREATE TABLE ContractTable(
ContactID INTEGER NOT NULL PRIMARY KEY, -- Possibly an autonumber
[various contract columns],
ParentContract INTEGER
);
Note, I know this is not Access friendly syntax. I usually use bigger DBs, but you should be able to get the idea.
Then your query to find parent contracts is SELECT ... FROM ContractTable WHERE ParentContract IS NULL.
To find sub contracts SELECT ... FROM ContractTable WHERE ParentContract IS NOT NULL.
My concern with this approach is that if you need to search through chains of contracts (i.e. A parent of B parent of C parent of D, and you need to go from A to D), you could run into recursive SQL which I don't think Access can handle. You'd have to do it VBA code.
I have recently stumbled upon a problem with selecting relationship details from a 1 table and inserting into another table, i hope someone can help.
I have a table structure as follows:
ID (PK) Name ParentID<br>
1 Myname 0<br>
2 nametwo 1<br>
3 namethree 2
e.g
This is the table i need to select from and get all the relationship data. As there could be unlimited number of sub links (is there a function i can create for this to create the loop ?)
Then once i have all the data i need to insert into another table and the ID's will now have to change as the id's must go in order (e.g. i cannot have id "2" be a sub of 3 for example), i am hoping i can use the same function for selecting to do the inserting.
If you are using SQL Server 2005 or above, you may use recursive queries to get your information. Here is an example:
With tree (id, Name, ParentID, [level])
As (
Select id, Name, ParentID, 1
From [myTable]
Where ParentID = 0
Union All
Select child.id
,child.Name
,child.ParentID
,parent.[level] + 1 As [level]
From [myTable] As [child]
Inner Join [tree] As [parent]
On [child].ParentID = [parent].id)
Select * From [tree];
This query will return the row requested by the first portion (Where ParentID = 0) and all sub-rows recursively. Does this help you?
I'm not sure I understand what you want to have happen with your insert. Can you provide more information in terms of the expected result when you are done?
Good luck!
For the retrieval part, you can take a look at Common Table Expression. This feature can provide recursive operation using SQL.
For the insertion part, you can use the CTE above to regenerate the ID, and insert accordingly.
I hope this URL helps Self-Joins in SQL
This is the problem of finding the transitive closure of a graph in sql. SQL does not support this directly, which leaves you with three common strategies:
use a vendor specific SQL extension
store the Materialized Path from the root to the given node in each row
store the Nested Sets, that is the interval covered by the subtree rooted at a given node when nodes are labeled depth first
The first option is straightforward, and if you don't need database portability is probably the best. The second and third options have the advantage of being plain SQL, but require maintaining some de-normalized state. Updating a table that uses materialized paths is simple, but for fast queries your database must support indexes for prefix queries on string values. Nested sets avoid needing any string indexing features, but can require updating a lot of rows as you insert or remove nodes.
If you're fine with always using MSSQL, I'd use the vendor specific option Adrian mentioned.