Access noob here, Trying to better a legacy system as the new one may not be ready for a couple of years :/ .
I currently have a table "tblFees" that has community and fees/rates for types of development; not all communities have the same fee types.
I have a form where a user selects a community, and then selects a fee type.
I want that fee type drop down to be contextual, to only display applicable fee types.
tblFees:
I currently have all of those fee types (plus about 20 more) in a single column "tblfeeType" table which is used in the drop down/combo box on the form.
So far I query by community and get a community name and a list of fees, How do I make it return the non-null field names in a list that can be used in my fee type combo box?
Any help is greatly appreciated.
Thnx
Related
This question already has answers here:
How can you represent inheritance in a database?
(7 answers)
How to design a product table for many kinds of product where each product has many parameters
(4 answers)
Closed 1 year ago.
I'm trying to build a letter of statement request system using MySQL as its DBMS. I don't know if "letter of statement request" is the appropriate term, but the system is meant to provide simplicity for college students to request a letter of statement from their faculty or university; such as active student certificate, research permit, etc. I have started to make the system but now doubt whether the database structure (just part of it) is ideal.
Here's the overall flow of how the system works:
Student sends a request for a letter of statement to the system. There are many available types of letters, but they can only request one type at a time.
Each type of letter will require different data to input. For example, an active student certificate requires the data of the current semester of the student and the destination institute where the certificate will be used; while a research permit requires the data of research title, the institute/place where the research will be held, time of research, research subjects, etc. This is where the confusion and doubt hit me.
The requested letter will be then gets verified by officers and will be sent to the student if gets approved.
Here's the (partial) database structure in question (Tailored for simplicity)
letter_type
type_id (primary key)
description
letters
id (primary key )
letter_type (foreign key)
submitted_at
necessity
letter_position
status
active_student
letter_id (primary key, foreign key)
semester
destination_institute
research_permit
letter_id (primary key, foreign key)
title
institute
duration
subject
The letters table is used to record the overall data of the letter, including the id of the student, type of the letter, submission date, etc.
The two other tables, active_student and research_permit, are used to record the 'detail' data of the letter. Meaning that the data of a request for an active student certificate will be written in letters and active_student, while a request for a research permit is written in letters and research_permit
letters table will use its letter_type field to determine which table it should be referencing.
Finally, here's the question:
Is my database structure ideal? If not, what's the better approach available?
Additional context
I'm making the system using Laravel 8. The code for creating a new record of letters is easy because each type of letter is handled by a different controller. The difficulty comes when I want to make the code for retrieving a set of letters' records (for example letters sent by a student with id 'X001'). What makes it difficult is because I need to retrieve records from the letters table along with its 'detail' data in the referencing table of each record (there are more than just two types of letters actually).
Actually, I would like to ask about how to do this in Laravel. But before that, I want to make sure that my database structure is correct.
This is a very good question in my opinion. You are worried that in order to enter the data for a particular request you need a table for that request with all its obligatory (and maybe optional) columns. Every time you want a new request type in your system, you'll have to add a table for this and change the software.
This is one of the few cases where a key/value table might be an appropriate choice. Here is an example:
letter_type (letter_type_no, name)
letter_type_field (letter_type_no, field_name, is_obligatory)
letter_request (letter_type_id, student_no, date, status)
letter_request_field (letter_type_id, student_no, field_name, field_value)
Key/value tables are a nuisance to work with. If you have just one table for them the values must be strings for instance and dates and numbers must be stored in an agreed format. Validity checks are hard to implement. The list goes on. But for a new letter type, you just add that type to the letter_type table and list all required fields in the letter_type_field table, and all your queries and software can work with this.
Another and probably better approach, though, may be to use a NoSQL approach. E.g. store the field list in an XSD and use this in your app to have the student fill in a form that you store as XML. It's simpler, and there will be a person looking at the request anyway, so they can point out missing or wrong data.
Good evening,
I write you after days of "thinking": D
I'm working on a WFM system that allows you to manage activities from the field.
But now the request to manage several different activities forced me to redesign the whole DB.
Originally only 2 types of activities were handled (Installation, Failures) and all was managed by a single database table with all the columns of one and the other activity. The unused column for a task assumed the null value and was not shown via PHP.
Now I have to understand how to structure a db that has the following characteristics:
- the user can configure endless types of different activities (Installation, Failure, Gardening, Reclamation, etc ...)
- the user can configure infinite properties / attributes (Client name, Surname, Address, Expiration date, etc ...)
- for each activity can be associated many properties (certainly not all)
- each property plus being associated with many activities (certainly not all)
- each property can take as many values as it is applied (N ° values = property X activity to which it is applied)
- the user does not have to choose the table in which to insert the property, whether this is called "Customer cousin name" or "IBAN for payment"
Making a practical example I can have that the properties of customer registry are used for each activity, but maybe the property "Height grass" is used only for the activity "Gardening"
Can someone help me? Thank you
We are using an older version of SAP and don't have access to the database itself.
The version is SAP ECC 6.0.
Can anyone tell me where I can find a unique employee Id/ number for an employee?
SAP No is no good as employees can have 2 positions and that would mean 2 different SAP numbers?
Any help would be appreciated.
Thanks
Your question is not really clear on what is the problem, and what you want to accomplish.
I assume you're speaking about the HCM/HR module.
An employee that belongs to several companies will possess several employeeid's. If an employee occupies two positions in the same company, it will have only one employeeid (field pernr in all infotypes tables). However, it has two relationship with "S" objects (Job) in OM.
If you have an employee in several companies, you can create a solution. There are a lot of ways to do so (as always with SAP). It depends also on what (sub) module you want to use ? PA ? OM ?
In the first case, you could use a field of the IT0032 (badge for example), or create a shared infotype, with a GroupId / UniqId that is filled during infotype creation.
In the second case, you could use the "CP" object (central Person) in OM to get a relationship with all the P objects (person / employeeId) of the employee.
It really depends on the HR Processes and the current customization of your SAP system.
SAP HCM has the transaction PA20 which display personnel data. Actually, the right name of transaction is: Display HR Master Data.
Execute PA20.
Look up the field you want.
Hit F1 over there.
Hit over hammer icon.
Look up field name and table name.
OR
to run SE16, accessing the table: PA0105 and column name: PERNR - Personnel number.
I've been using Access to create simple databases for a while with great success, but have run into a problem I can't find an answer to.
We ship individualized serialized units to various end-users, and occasionally to resellers that stock them for end-users. I must keep track of which serial numbers end up with each end-users.
The first database I created to handle this recorded company information in one table using their account number as primary key, order information in a second table using the order number as the primary key and linked via the company name, and unit information in a third table with the serial number as the primary key and linked via the order number.
This worked very well until I had to account for these stock orders with a reseller. As it was structured, every unit was linked to one company via the sales order. The issue is that I may ship 20 units on one order to Company A, who then sells 5 to Company B and 3 to Company C.
I realized I needed to link the company name directly to the units, not the orders and have fixed that.
My issue now is simplicity in entering information in the form. My previous database involved the employee in our shipping department merely entering the sales order, selecting the customer name from a drop down menu, then scanning the serial numbers in a subform. This was to ensure simplicity and try to eliminate human error. He had only three things to input, and most of the input was done by scanning barcodes.
As it is currently structured now, the employees out in shipping would have to populate the company name for every record in the subform with the serial number and that complicates things in a way that is unacceptable. At the point of shipping, the company name will always be the same for every unit in the subform.
So.
How would I go about creating a form where the company name is entered once in the form, and automatically populates itself for every record in the subform? The caveat here is that I must also be able to go back occasionally and change the company name of individual units in an order without necessarily affecting the rest of the order. I suppose it starts out as a one-to-many relationship that then must be able to change.
I hope that makes sense.
I have looked for answers using various approaches with auto-fill and relationships and not preserving data integrity, but I feel the answer is just beyond my reach.
The only solution I can think of is to create another field in the unit table for the end-user, and perhaps write a formula that sets this default value as the company name from the order that shipped it. This seems unnecessarily complicated and redundant, there has to be a better way.
So I have this application that I'm drawing up and I start to think about my users. Well, My initial thought was to create a table for each group type. I've been thinking this over though and I'm not sure that this is the best way.
Example:
// Users
Users [id, name, email, age, etc]
// User Groups
Player [id, years playing, etc]
Ref [id, certified, etc]
Manufacturer Rep [id, years employed, etc]
So everyone would be making an account, but each user would have a different group. They can also be in multiple different groups. Each group has it's own list of different columns. So what is the best way to do this? Lets say I have 5 groups. Do I need 8 tables + a relational table connecting each one to the user table?
I just want to be sure that this is the best way to organize it before I build it.
Edit:
A player would have columns regarding the gear that they use to play, the teams they've played with, events they've gone to.
A ref would have info regarding the certifications they have and the events they've reffed.
Manufacturer reps would have info regarding their position within the company they rep.
A parent would have information regarding how long they've been involved with the sport, perhaps relations with the users they are parent of.
Just as an example.
Edit 2:
**Player Table
id
user id
started date
stopped date
rank
**Ref Table
id
user id
started date
stopped date
is certified
certified by
verified
**Photographer / Videographer / News Reporter Table
id
user id
started date
stopped date
worked under name
website / channel link
about
verified
**Tournament / Big Game Rep Table
id
user id
started date
stopped date
position
tourney id
verified
**Store / Field / Manufacturer Rep Table
id
user id
started date
stopped date
position
store / field / man. id
verified
This is what I planned out so far. I'm still new to this so I could be doing it completely wrong. And it's only five groups. It was more until I condensed it some.
Although I find it weird having so many entities which are different from each other, but I will ignore this and get to the question.
It depends on the group criteria you need, in the case you described where each group has its own columns and information I guess your design is a good one, especially if you need the information in a readable form in the database. If you need all groups in a single table you will have to save the group relevant information in a kind of object, either a blob, XML string or any other form, but then you will lose the ability to filter on these criteria using the database.
In a relational Database I would do it using the design you described.
The design of your tables greatly depends on the requirements of your software.
E.g. your description of users led me in a wrong direction, I was at first thinking about a "normal" user of a software. Basically name, login-information and stuff like that. This I would never split over different tables as it really makes tasks like login, session handling, ... really complicated.
Another point which surprised me, was that you want to store the equipment in columns of those user's tables. Usually the relationship between a person and his equipment is not 1 to 1 and in most cases the amount of different equipment varies. Thus you usually have a relationship between users and their equipment (1:n). Thus you would design an equipment table and there refer to the owner's user id.
But after you have an idea of which data you have in your application and which relationships exist between your data, the design of the tables and so on is rather straitforward.
The good news is, that your data model and database design will develop over time. Try to start with a basic model, covering the majority of your use cases. Then slowly add more use cases / aspects.
As long as you are in the stage of planning and early implementation phasis, it is rather easy to change your database design.