Not Sure How To Make This Change
-
Working on a WPF app. Currently, I have a table in SQL called Lookups that contains all kinds of lookup data. Here is a set of that data called Employee Types.
Caption Category AppCode
Director of field Operations employee_types director_of_field_operations
Drafting employee_types drafting
Driver employee_types driver
Estimator employee_types estimator
Foreman employee_types foreman
General Forman employee_types general_forman
Office employee_types office
President employee_types president
Project Coordinator employee_types project_coordinator
Project Manager employee_types project_manager
System Administrator employee_types system_admin
Vice PresidentEach employee is assigned an Employee Type. I can the query for specific types of employees. For example, there is a Foreman report that gets all employees who's EmployeeTypeId is in the Lookups of AppCode 'foreman' or 'general_forman'. The AppCode is defined by me when I create new Lookup entries so I can reference them in code. The problem is, now my client wants to be able to add and remove employee types via the UI. I don't see how I can allow them to manage this list without the AppCode. I would have nothing to key off of when running reports or sending automated notifications to people in specific roles. I can provide more detail if needed. Any ideas on this?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
-
Working on a WPF app. Currently, I have a table in SQL called Lookups that contains all kinds of lookup data. Here is a set of that data called Employee Types.
Caption Category AppCode
Director of field Operations employee_types director_of_field_operations
Drafting employee_types drafting
Driver employee_types driver
Estimator employee_types estimator
Foreman employee_types foreman
General Forman employee_types general_forman
Office employee_types office
President employee_types president
Project Coordinator employee_types project_coordinator
Project Manager employee_types project_manager
System Administrator employee_types system_admin
Vice PresidentEach employee is assigned an Employee Type. I can the query for specific types of employees. For example, there is a Foreman report that gets all employees who's EmployeeTypeId is in the Lookups of AppCode 'foreman' or 'general_forman'. The AppCode is defined by me when I create new Lookup entries so I can reference them in code. The problem is, now my client wants to be able to add and remove employee types via the UI. I don't see how I can allow them to manage this list without the AppCode. I would have nothing to key off of when running reports or sending automated notifications to people in specific roles. I can provide more detail if needed. Any ideas on this?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
When they create a new type (via a dialog) check for existing, then suggest a "code" based on the entered content after checking for an existing code. This is the drawback of using a "code" and also storing different types of data in the same table - classic mistake. I know the argument that they are all lookups and they are all simple UNTIL THEY ARE NOT! You now have to faff about working around the problem instead of having an EmployeeType table with an ID as the primary key.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
When they create a new type (via a dialog) check for existing, then suggest a "code" based on the entered content after checking for an existing code. This is the drawback of using a "code" and also storing different types of data in the same table - classic mistake. I know the argument that they are all lookups and they are all simple UNTIL THEY ARE NOT! You now have to faff about working around the problem instead of having an EmployeeType table with an ID as the primary key.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
But the problem is that my code can never know what the code is.
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
-
Working on a WPF app. Currently, I have a table in SQL called Lookups that contains all kinds of lookup data. Here is a set of that data called Employee Types.
Caption Category AppCode
Director of field Operations employee_types director_of_field_operations
Drafting employee_types drafting
Driver employee_types driver
Estimator employee_types estimator
Foreman employee_types foreman
General Forman employee_types general_forman
Office employee_types office
President employee_types president
Project Coordinator employee_types project_coordinator
Project Manager employee_types project_manager
System Administrator employee_types system_admin
Vice PresidentEach employee is assigned an Employee Type. I can the query for specific types of employees. For example, there is a Foreman report that gets all employees who's EmployeeTypeId is in the Lookups of AppCode 'foreman' or 'general_forman'. The AppCode is defined by me when I create new Lookup entries so I can reference them in code. The problem is, now my client wants to be able to add and remove employee types via the UI. I don't see how I can allow them to manage this list without the AppCode. I would have nothing to key off of when running reports or sending automated notifications to people in specific roles. I can provide more detail if needed. Any ideas on this?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
As Mycroft said, stuffing every lookup into a single "lookups" table is a bad idea. It makes life much harder when you want to evolve a single type of lookup. Start by moving the employee types to its own table. The next step will depend on your precise requirements:
- If you only ever want to report on a specific group of employee types, then replace the
AppCodewith a lookup to an "employee type group" table. When the user adds a new employee type, let them select the appropriate group, so that those types can be included in the relevant reports. - If you need more flexible grouping for your reports, add a many-to-many relationship between the employee type and the employee type groups. You can optionally let the user add the new types to one or more groups; if they don't, then those types won't be included in the reports.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
- If you only ever want to report on a specific group of employee types, then replace the
-
Working on a WPF app. Currently, I have a table in SQL called Lookups that contains all kinds of lookup data. Here is a set of that data called Employee Types.
Caption Category AppCode
Director of field Operations employee_types director_of_field_operations
Drafting employee_types drafting
Driver employee_types driver
Estimator employee_types estimator
Foreman employee_types foreman
General Forman employee_types general_forman
Office employee_types office
President employee_types president
Project Coordinator employee_types project_coordinator
Project Manager employee_types project_manager
System Administrator employee_types system_admin
Vice PresidentEach employee is assigned an Employee Type. I can the query for specific types of employees. For example, there is a Foreman report that gets all employees who's EmployeeTypeId is in the Lookups of AppCode 'foreman' or 'general_forman'. The AppCode is defined by me when I create new Lookup entries so I can reference them in code. The problem is, now my client wants to be able to add and remove employee types via the UI. I don't see how I can allow them to manage this list without the AppCode. I would have nothing to key off of when running reports or sending automated notifications to people in specific roles. I can provide more detail if needed. Any ideas on this?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
You have an application enum and now the requirement is to allow customers to manage the enum as well. So first decision is one of these 1. Open it up entirely. 2. Allow them their own additional enums. Only the additions can be modified. If the there is only one customer per table (how ever you designed that) then the caption can be under user control completely for all enums with the following rules 1. Must not be empty. 2. Must not be a duplicate of another. Then the decision is how to store them. Probably easiest is going to be to add another column which flags it as a user value. Then the other changes 1. Provide a UI to manage them. I would just show all of them. This is required to manage the caption anyways (above.) But also allows them to see groupings. The flag controls whether they can delete them. Naturally you will need a length limit. 2. Figure out how to allow the usage. The second is tricky if you store them in another table. Such as a custom report. If so then you must either force them to remove the usage first before deleting or you must do it yourself.
-
Working on a WPF app. Currently, I have a table in SQL called Lookups that contains all kinds of lookup data. Here is a set of that data called Employee Types.
Caption Category AppCode
Director of field Operations employee_types director_of_field_operations
Drafting employee_types drafting
Driver employee_types driver
Estimator employee_types estimator
Foreman employee_types foreman
General Forman employee_types general_forman
Office employee_types office
President employee_types president
Project Coordinator employee_types project_coordinator
Project Manager employee_types project_manager
System Administrator employee_types system_admin
Vice PresidentEach employee is assigned an Employee Type. I can the query for specific types of employees. For example, there is a Foreman report that gets all employees who's EmployeeTypeId is in the Lookups of AppCode 'foreman' or 'general_forman'. The AppCode is defined by me when I create new Lookup entries so I can reference them in code. The problem is, now my client wants to be able to add and remove employee types via the UI. I don't see how I can allow them to manage this list without the AppCode. I would have nothing to key off of when running reports or sending automated notifications to people in specific roles. I can provide more detail if needed. Any ideas on this?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
... "and remove". Total disaster. Breaks referential integrity. The only way to "remove" "codes" is to "expire" them with a start and end date.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
