I am struggling to get a Hierarchical recursive query to work, I found some samples on the net but they all show the manager-employee level which does not seem to work for me. I have this issue, I have a list of organisations and I need to extract the ID of all employees. So I need to provide the top level employees, then find all the branches and all the employees for the branches. I tried adapting the examples and get excessive recursion errors, any help very gratefully received !
Ok so the structure I have is a contact table like this
SerialNumber
Name
Where the entry in the contact table is either a head office, a branch or an employee
and a relationship table
Parent
Child
DescriptionID
In this instance the head office is a parent with child entries that are employees or branches defined by DescriptionID, so I need to provide a SerialNumber as a parent to anchor then find all the branches and employees under this parent (defined as child in the relationship), then add all the employees of all the branches (child of the branch where the branch serialnumber is a parent in the relationship table)
Thanks
Related
I have 3 tables:
What I have: 2 pages;
ONE where an admin can add a project's name and the id will be autogenerated and
TWO (currently working on) Add and user with its name, ID to the USERS table, and select a project from the PROJECTS table, so after it gets added, display that info, either the users and the projects they belong to, or the projects and the users it contains.
In this page I am already displaying the projects from the PROJECTS table in a checkbox, since they can belong to several projects, but I need to display: userName, projectName and probably later the IDs, in a table when they get added.
How can I add that info to the child table and show the columns values from its parents tables? projectName and userName
Any help and suggestions are highly appreciated.
PS: I'm not good with databases so I'm probably missing something obvious here.
Better to use userId from "users" table as FK in "projects" table.
This question already has answers here:
How can you represent inheritance in a database?
(7 answers)
Closed 2 years ago.
I am building a Postgres database which has the following two tables:
Projects (id, startDate, etc...)
and
Employees (id, name, etc...)
I want to keep track of the types of contributions that an employee adds to a project. For example, employee #1 might be an "engineer" on project 1 and a "manager" on project 2. I also don't want to restrict the number of contributions an employee can make to a certain project. So employee #1 could be both a "engineer" and a "manager" for a single project.
My first instinct was just to have a many to many relation between the two titled ProjectEmployees or something and store the projectId, employeeId, and a contributionType as a string which would only take on values from an enum as to not have to deal with misspellings or any related issues.
My main question is just whether or not this is a bad practice. My other thought was to split up each contribution type to its own table. So instead of an EmployeeProjects table, there would be tables such as ProjectEngineers, ProjectManagers, etc... and instead of storing the contributionType as a column, it would be implicit in the table I'm using, and the table only has to store projectId and employeeId. There are many more tables in this database which have a similar sort of relationship where there are many to many relations between different tables, but each relation could be one of many "types" of relations. Is it wiser to split these all into separate tables for each type of relation? Or is it better to just keep track of the relation type in a more general table like my first idea?
My desired result is to just be able to efficiently see which all project contributions (and types) an employee worked on as well as to see all contributors + contributor types for a project.
Use the many to many relation as in your first idea, which in my opinion is a good practice.
Avoid the creation of one table per contribution type as is not scalable and flexible. I.E. if one day you'll have a new contribution type, with the 2nd option you will need each time
to create a new table
to write the new table management logic
proceed with a new deploy of your sw
About the topic of storing the contribution types on a table (with id and description) or as a constraint with contribution types strings enumerated, in my opinion both are valuable solutions.
But if you think to manage contribution types in your software (in a first release or in the future) maybe having a table with contribution types anagraphics can be better. It depends by your design and requirements
Make a table to store contribution types as strings (manager, engineer, etc) and contribution type id (numeric id). This prevents misspellings.
Make a table to store contributions with columns: employee id, project id, contribution type id (you may want other columns there, but it should be unique on the combination of these 3 columns). Do not store contribution types as strings in a table like this, since, as you correctly mentioned, this may allow misspellings. Another reason is to save disk space. An extra join with a small table of contribution types is a small price to pay.
Is it possible to reference additional columns apart from the 'Code' and 'Name' columns when using a domain attribute in an entity?
E.g. A person entity has a code of '1' and a name of 'Smith' and a Gender of 'Male'
In a customer entity there is a domain value referencing the person entity which displays the following 1 {Smith}. The users would like an additional read only attribute which would copy the Gender value of 'Male' into the customer entity based on the domain value. Can this be done using out of the box MDS UI?
I know this is duplicate data and breaks normal form but for usability this would be useful. It would be the equivalent of referencing additional columns in an MS Access drop down list.
Many thanks in advance for any help
This is not possible with the standard UI. One option would be to develop a custom UI where you can handle these kind of requests.
If you want to stick with the standard product I can see a workaround but this is a bit of a "dirty" one.
You can misuse (abuse) the Name attribute of the Person entity by adding a business rule to the Person entity that generates the content of the Name attribute as a concatenation of multiple attributes. You of course need an additional attribute that serves as a place holder for the original Name. The concatenated field will then show in your customer entity.
One question that does come to mind is why a user would like/need to see the gender of a person in a customer list? As you have a separate Person entity I expect you to have multiple persons per customers. What would the gender of one person - even if it is the main contact - matter?
I'm new to Filemaker, but have extensive SQL experience.
How do I add a list of children to my Filemaker layout, if I have a one-to-many relationship (a tree)? I would like to see for my current node all its children. Later I want to filter them as well.
Showing the parent is easy via the related field. But for the reverse it appears that I need to use scripts?
In SQL, I would write:
SELECT * from Element WHERE parent = {current_id};
You set up a relationship between the tables in the relationship graph using a primary key and foreign key arrangement. Then you add a portal to the related table occurrence on your main table layout. You can add filtering in the relationship itself or in the portal afterwards.
I advice you to check out this info from FileMaker on the subject.
i have a many to many table relationship that involves 2 logical tables.
Record table that joins to a relation table on primaryID
Second instance of record table that joins to the relation table on ReciprocalID
The purpose of this is to show family relations within the database. Each primary Record table has one or more rows in the relationtable that shows everyother family relationship this person has in the database.
I have been tasked with trying to make a contact list that involves displaying the names of each of the children that attend this school along with their parents and contact information.
I have gotten to a point where I am able to show the children under each parent, but now I have to find a way to merge these together.
Since I have no control over the design of this database(its Education Edge 7) I have made a separate database that holds my queries and views for my reports. The school I am doing this work for only has access to CR 8.5.
Right now I have my top group in CR as the lastname of the recordstable, my second group is on the fullname of the recordstable. I have a subreport that pulls in all the child records.
I have used a case when statement in my primary view(the one described above) to convert 'daughter' and 'son' to child and 'mother' or 'father' to parent.
hopefully this hasnt rambled too much. If you need anymore information just ask.
SELECT dbo.vwEA7RelationshipsTableView.PRIMARYID,
dbo.vwEA7RecordsTableView.LASTNAME AS PRIMARYLASTNAME,
dbo.vwEA7RecordsTableView.FIRSTNAME AS PRIMARYFIRSTNAME,
dbo.vwEA7RecordsTableView.NAMEFORDISPLAY AS PRIMARYNAME,
CASE dbo.vwEA7RelationshipsTableView.PRIMARYDESC
WHEN 'Father' THEN 'Parent'
WHEN 'Mother' THEN 'Parent'
WHEN 'Son' THEN 'Child'
WHEN'Daughter' THEN 'Child'
ELSE dbo.vwEA7RelationshipsTableView.PRIMARYDESC
END AS PRIMARYDESC,
dbo.vwEA7RelationshipsTableView.RELATIONID,
vwEA7RecordsTableView_1.LASTNAME AS RELATIONLASTNAME,
vwEA7RecordsTableView_1.NAMEFORDISPLAY AS RELATIONNAME,
dbo.vwEA7RelationshipsTableView.RELATIONDESC
FROM dbo.vwEA7RelationshipsTableView INNER JOIN
dbo.vwEA7RecordsTableView ON
dbo.vwEA7RelationshipsTableView.PRIMARYID = dbo.vwEA7RecordsTableView.ID INNER JOIN
dbo.vwEA7RecordsTableView AS vwEA7RecordsTableView_1 ON
dbo.vwEA7RelationshipsTableView.RELATIONID = vwEA7RecordsTableView_1.ID
TableViews are really just recreation of the primary tables from the main database.
I have solved this issue. My sql code was good, it was a matter of formatting my internal paramaters for Crystal as well as some creative grouping.