Search the Community
Showing results for tags 'hierarchy'.
Found 4 results
Hi every body I have ancestor database "test file" attached . I need a script that gives me theses search results: If I search for a single name, I want to find the records where the last field is the "single name" If I search for two names "Smith George", I want to find only records with the last two fields having the two names "Smith as the son and George as the father" If I search for three names "Smith George John", I want to find only records with the last three fields having the three names "Smith as the son and George as the father and John as the grandfather" Search parameters------------Output (result) John-------------------------------2 results : REC3 (George, Smith, John) and REC6. Smith George ------------------ 2 results : REC2 (George, Smith) and REC9. Smith George John ----------- 1 result : REC9. Thank you all test file.fp7
Hi, I would like some advise on how to setup a database containing a (biology) taxonomy. I'll explain the idea. I will have a main table with information about a species and the taxonomy linked to this information. It's the taxonomy part that I'm not sure about what is the best way op setting it up. It contain species, genus, family and so on. (About 10 rank levels) After searching on the web I have the following ideas. 1. I make one table containing: ID, name, rank, parentID Then creating 10 (for each taxon rank) table occurrences relating parentID to ID. 2. Create 10 tables, one for each taxonomy rank with: ID, name, parentID and relate these also by parentID > ID. 3. I haven't figured out yet how this would workand what the advantage is, but I read about a join table used for a taxonomy ? So one table with name and rank and one with id and parentid ? One thing is that somethimes I will have a level in the taxonomy missing, for example, there will be a species name, and the next one will be a family name, so genus will not be used. This isn't a problem with option 1 as the parentID will be there. For option 2 that means I'll have to make an empty record (but with ID and parentID) to not break the chain. What option would you advise me to use ? Or suggesting another better option. ;-) I also want to make a single form to add a new species with the connecting taxon as easy as possible. Will these different options have a big influence on this or does it require a fair ammount of scripting anyway ? I hope you can help me selecting the best setup for my database.
I think I'm constructing a Rube Goldberg-esque solution to my problem. Here's the application domain. I have a table of records that correspond to patent applications, which are commonly referred to as matters. A matter can claim (but does not have to) immediate priority to one and only one other matter. However, more than one matter can claim priority to the same matter, and a matter that has matter(s) which claim priority to it can itself claim priority to a matter. When a matter claims priority to another matter, this means that the former matter is of lower priority than the latter matter. I realize this is confusing, so here's a concrete example that I've been using for testing purposes. Say there are seven matters A, B, C, D, E, F, G. B and C claim priority to A, and are thus of lower priority than A. D and E claim priority to B, and are thus of lower priority than B and A. F and G claim priority to E, and are thus of lower priority than E, B, and A. For what it's worth, I created another table called priority, which lists two matters, the matter claiming priority, and the matter to which it claims priority. So, in the example, there are six records in this new table, one for each priority relationship. In hindsight, this is perhaps not needed, since in my main matter table, I could simply have a matter refer to another matter to which it claims priority. Now, the problem. Per the concrete example listed above, the result of matters claiming priority to other matters effectively results in a hierarchical tree. I want to list all the matters that are in the same tree -- that is, all the matters in any priority chain. So, regardless if I start at matter A, B, C, D, E, F, or G, I end up with the same list of matters. Here's how I've done this. I have a first script that finds the highest priority matter in the tree. So, if you started at A, you're OK, because A is the highest priority. But if you start from E, say, it would find B as being of higher priority, and then finally find A as being of highest priority. That is, regardless of whether you start at A, B, C, D, E, F, or G, you always end up at A. Then, this script calls a second script that recursively calls itself. The second script has a parameter that is a current matter. It locates any matters that claim priority to the current matter. If there are any such matters, for each of these matters the script calls itself again, to determine whether there are any matters that claim priority to these matters. This recursion continues until it locates all matters that do not have any other matter claiming priority to them. This indeed works as expected. Once we get to A in the first script, the call to the second script passing A finds B and C. For each of B and C, the second script calls itself. When the second script is operating on B as the current matter, it finds D and E, and when operating on E as the current matter, it finds F and G. What I don't like about this approach is that there is a *LOT* of searching going on. But it does work. The idea is that once I get all the matters in a family -- i.e., all of A, B, C, D, E, F, and G -- I can list these applications in a layout, and long-term, call some (external) tree building tool appropriately to create a visual representation. Critically, though, a user is just going to specify at most one priority relationship for any given matter, that the given matter claims priority to (and thus is of lower priority than) another matter. From these priority relationships, then, I need to figure out the family of matters.