I have a parent row and child rows on 7-10 separate tables, with a unique key tying the rows on the child tables to the parent row. For a search feature, I need to retrieve the parent and all the matching child rows, based on a query against the data in the parent table. There are up to 5000 matching parent rows. Currently we are re-running the query against each of the child tables, like:
select data from child
where key in (select key from parent where search_criteria)
This seems pretty inelegant especially as we continue to add more child tables. Is there a better way to do this in DB2?
Some of my thoughts:
Will DB2 reuse the results of that select? What about if there is a high volume of queries?
I know the keys after the parent query, so I could pass them in the SQL, but that SQL would get crazy with 5000 keys, and presumably exceed the SQL limit.
Would it be worth it to store the keys as a temp table, or would the setup / teardown be excessive?
This sounds like an ideal scenario to use a RPG program and use a stored procedure that calls/consumes it. This way, you're not making so many round trips. Pass your search criteria to the stored procedure and the stored proc invokes the RPG program. Let RPG chain the 'files' together, which would speed up your query.
Related
Pre-cursor: I am very new at trying to code.
Problem: I am trying to create a query that will determine cumulative cycletimes for products. The issue that I am having is that the data is structured in the tables in such a way that you have to determine what flows have children by continuing to drill through the BOM.
Example:
Items in column 2 that are FD are children of a parent, but are also parents themselves. I need to be able to identify them and then get to their children as well in the same query.
I am wondering what the most efficient way to do that is.
Thank you.
I'm trying to figure out how I can store hierarchical type information in a MS Access DB so that queries will be faster. An use case example might make more sense.
I have a table that has two fields
a name
a hierarchy
a hierarchy is an X # of level folder structure:
\a\b\c\d
\a\b\c\d\e
\a\b\c\d\f\g
\a\b\h
\a\b\i\j
you get the idea
the table will be filled with 300,000 rows
each row will have a name and a hierarchy
At this point:
if I want to find all the names that are in a hierarchy, including sub-hierarchies I can run a like query: where [hierarchy] like '\a\b\*'
I can even do wildcard joins even though MS Access's query design GUI doesn't handle it and I have to use the SQL view: join on [hierarchy] like '\a\b\*'.
But it can be very slow. Especially if my joins get complex.
So I thought maybe there is a way to create another table that would all the hierarchies and it would maintain parent/child relationships and the first table would reference a row in it. And then, somehow, I could use it to find rows in the first table that match hierarchies and sub-hierarchies in the second table.
However, I have no clue if this is even possible and how I would go about it. Any advice is appreciated.
In Oracle we use the hierarchal structure where each row has a reference to its parent. Then with the CONNECT BY clause you can connect these rows to each-other.
You should take a look here: simulation of connect-by in sql-server
TASK
I am currently trying to work out a viable structure for a simple application for the costing of jobs. I have decided to create one table to house all the operations and then link the operation together via a ParentID field. Below is a simplified structure of this table:
As you can see, the primary key is an integer field that does auto increment to keep it unique. Any operations that stem off another operation will have it under the parent ID field to create a simplistic breakdown of work flow. Also on this data table is a field for costs, this is a field that I am most interested in.
THE PROBLEM
I would like to run a query where I could throw in an operation ID and it would recursively run through that operation AND all of its children and its children's children etc. This would then accumulate all of the cost fields in the records that it retrieves. The only way I can think to do this is through recursive loops which in my opinion are not the best way to do this.
THE QUESTION
So, my question is, is there a way to do this without recursive loops? If there is not, can anyone suggest the cleanest and quickest way with the loops?
This kind of query is recursive by definition. There is no way to get that information using that table structure.
You could make another table in which you would store all hierarchy information. On inserting an Operation you would have to add a parent, grandparent, grand-...-parent recursively, which may also not be a good idea, because the table would grow very large very quickly. It would make the queries much simpler though.
And a side note: I'd suggest naming the ParentID ParentOperationID. ParentID is too general.
We receive bulk data from our customers in a spread sheet. I loaded them in a temporary table as of now. I tried to normalize the data and create a parent table and each parent to have 4 or 5 child rows. Is there a way to insert all the parents and their children using queries? I dont want to write an Application to do that
If you're specifically looking to write only queries to perform this task, check out the following article that outlines a way to set up a linked server to an excel doc.
http://www.sql-server-helper.com/tips/read-import-excel-file-p01.aspx
If you get this set up correctly (which can be a pain) it's as easy as querying the data directly.
I need to create a sql stored procedure (Sql Server 2008 - T-SQL) which copies a node in an adjacency model.
Table can be seen as having two columns, Id and ParentId (FK to Id). Copying means that also all subordinates need to be copied.
I think that using WITH is a good start, but I'm curious if I can do this copy without using Cursors.
The fundamental problem with adjacency lists is there is no general way in SQL to extract an entire sub tree, so you already have a problem of identifying all the rows you need to duplicate without resorting to a cursor.
If possible migrate your adjacency list to a nested set model which allows you to easily identify all the nodes of a subtree. However, the maintenance of a nested set model is more complex for general inserts and deletes.
EDIT: As pointed out by 'a_horse_with_no_name' there is a way in general SQL to process adjacency lists, recursive common table expressions.
Copying a whole sub-tree is a bit of a problem because when you copy your sub-tree you are either
denormalizing data or
using it as a template of some sorts.
In either case you are dragging data through inconsistent state at some point - which indicates some problems with your design (for example do your records need to have multiple parents or not? if yes, then you should consider redesigning).
So, you should update the answer with a more complete example of what you are trying to do.
One solution would be to have a temporary table, selecting for the insert should not be a problem, it is just updating the referenced IDs that would be a problem.
So
WITH INSERT into temporary table
UPDATE the IDs
INSERT into original table
DELETE temp records
The procedure needs to go like this because it would be hard to change the IDs (both record IDs and ID referring to parent) in initial WITH INSERT. However it might be possible, if there was a nice function that depended only on max_id or only on old IDs.