I am trying to create a database that will be used by multiple teams in my company that displays their daily stats.
When you open up the database I have a combo box that allows you to select your team name. Once you make your selection, your form appears with your team stats for the day. (In reality it's just one form that has a subform with a query. The query is updated when you select your team from the combo box)
Each team has their own separate set of stats for each day and they are only allowed one entry per day. Not every single team has the same category of stats. This is an example of some of my tables
Quality Stats Table:
Team Name | Daily # | Actual # | Goal # | DateOfEntry
Productivity Table:
Team Name | Percentage | DateOfEntry
Stop Ship Table:
Team Name | Yes/No | DateOfEntry
How do I make it so that each team can only have one entry in each table per day?
I have my Team Names linked across all the tables, but I am having a hard time enforcing the one entry per date restriction
I am very new at access and I am still trying to figure it out. I would greatly appreciate it if someone can point me in the right direction
Create a multiple-field unique index on each of those tables. Here is an example for the Quality Stats table ...
strSQL = "CREATE UNIQUE INDEX idxQualTeamDate ON [Quality Stats] ([Team Name], DateOfEntry)"
CurrentProject.Connection.Execute strSQL
The same thing can also be done through the Access user interface. If you prefer to go that route, it might still be helpful to execute the CREATE UNIQUE INDEX statement I gave you and then open the table in Design View to see how Access presents it there.
Related
Let me describe briefly the table structures:
Customer Table
id | name | address_line_one | address_line_two | contact_no_one
SaleInvoice Table
id | id_Customer (Foreign Key) | invoice_no
If I have to print a Sale invoice, I have to use the Customer information (like name, address) from the Customer table.
Assume that after a year, some customer data changes (like name or address), and I update the new data in my customer table. Now, if the customer asks for an old invoice, it will be printed with the new customer data which shall be legally wrong.
Does that mean, I have to create
name_customer
address_line_one_customer
...
and all these fields in the Sale Invoice table too?
If yes, is there a better way to get data from these fields in Customer table to the Sale Invoice table then to write a SQL query to get the values and then set the values?
This is really up to you. In some cases, where it is a legal document, you will save all the details so that you can always bring it up the way it was created. Alternatively if you are producing pdf invoices then save them to be 100% sure.
The other alternative is to create a CustomerHistory table, so that past versions are always saved with a date range, so that you can go back to the old version.
It depends on the use cases, but those are your main options.
It sounds like a problem easily solved by placing the Employee table in version normal form (VNF). This is actually just a flavor of 2nf but done in a way that provides the ability to query current data and past data using the same query.
A datetime parameter is used to provide the distinction. When the value is set to NOW, the current data is returned. When the value is set to a specific datetime value in the past, the data that was current at that date and time is returned.
A brief discussion of the particulars can be found here. That answer also contains links to more information if you think it is something that would work for you.
I am going to be developing a multi-user web app where users will record every day whether or not they have completed various tasks. The tasks are repeated every day, eg: Every day XYZ needs to be done.
Not all users will have the same tasks to complete each day. There will likely be a database table containing all possible tasks. When a new user signs up on the web, they will select the tasks that apply to them by creating a profile for themselves.
Each day the user will then record whether or not they completed their respective tasks. Following that, there will be in depth reporting and historical stats not just on a users own task history,...but also globally to look for trends.
Im just looking for any suggestions on how to design the database (in general terms). Would it be ok to have a task table that contains all the tasks. Then when a new user creates their own profile online, a brand new table is created with their profile information and the tasks that they have selected. Each unique user profile table will then contain an ongoing history of tasks completed each day.
Or is there a better way to design this?
Edit: Or would a better idea to be to have something like the below:
Task history table:
PersonID | Date | Task1 | Task2 | Task3 | Task 4
001 | 24Jan15 | Complete | Complete | |
002 | 24Jan15 | | Complete | Complete | Not Complete
003 | 24Jan15 | Not Complete | | |
So there would be one table containing all the users (and the tasks they've chosen), another table containing all possible tasks, and lastly the above table recording the task history each day.
The only issue here is that not every task is applicable to every person. So there will be blanks. Not sure if that matters.
As you can no doubt tell, im a beginner. So any advice would be appreciated.
It is almost never a good idea to create new tables dynamically to hold subsets of the data. Data for different users should go in the same set of tables, with some field identifying the user. There is no good reason to have hundreds of tables that are all identical except that one is for some key value A, the next is for key value B, etc. Just add the key field to the table.
As a_horse_with_no_name says, numbered columns is a strong sign that you are doing it wrong. There are many reasons why this is a bad idea. Among them: If you have one column for each task, what happens when a new task is added? Instead of just adding a new record, now you have to add a new column to the table, and update all the existing records. Also, it makes queries very complicated. A query like "what tasks were done today" requires a separate test for every column, instead of one test on a single "task" column.
From what you've said, here's my first thought on how this should look:
Task table
(task_id, task_name)
This lists all the tasks of interest.
User table
(user_id, user_name)
This lists all the users.
Assigned_Task table
(user_id, task_id)
This relates users to tasks. There will be one record in this table for each task for each user. That is, if Alice is user 1 and she is supposed to do tasks 1, 2, and 3; and Bob is user 2 and he is supposed to do 2 and 4, then there will be records (1,1), (1,2), (1,3), (2, 2), and (2,4).
(Note: You might have an assigned_task_id field for this table to be the primary key, or the PK could be user_id + task_id, as that must be unique.)
Task_Status table
(user_id, task_id, task_date, completed)
This will have one record for each user/task combination, for each day. So after 30 days, if Alice has 3 tasks, there will be 3 x 30 = 90 records for her, 3 for each day times 30 days.
(You might have a task_status_id as the PK, or you might use user_id + task_id + task_date. Keys with more than 2 fields tend to be a pain so I'd probably create a task_status_id. Whatever.)
Any of these tables might have additional fields if there's other information you need. Like the User table might have employee number, phone number, department, etc.
Then a question like, "What tasks were not completed yesterday?" is easily answered with this query:
select user.name, task.name
from task_status
join user on user.user_id=task_status.user_id
join task on task.task_id=task_status.task_id
where task_date=#date
and completed=0
How many tasks were completed today?
select count(*)
from task_status
where date=#date and completed=1
Etc.
I have several list boxes in my web application that user has to fill. Administrator can add/remove/edit values in the combo box from controle panel. so problem is what is the best way to keep these combo box in database.
one way is keeping each table for each combo box. I think this is very easy to handle but I will have to create more than 20 tables for each combo/list box.And I think whether it is good practice to do so.
anotherway is keeping one table for all combo box. But I am worring when deleting data in this case.
If I want to remove India from countr coloum in combo box table, then I will be in problem. I may have to update it to null or some otherway and have to handel this in programming side.
Am I correct. can you help me ?
I think you just should create a table with 3 fields. First field is the id, second is the name and the last is the foreign key. For example:
combo_box_table
id - name - box
1 - Japan - 1
2 - India - 1
3 - Scotland - 2
4 - England - 3
you just have to play with query, each box represent the last field. 1 represent combo box 1 and 2 represent combo box 2 etc.
select * from combo_box_table where box = 1
if you want to delete india the query is just delete from combo_box_table where id = 2
May this help
Another possibility would be to save the combo box data as an array or a json string in a single field in your table, but whether you want to do this or not depends on how you want your table to function and what you application is. See Save PHP array to MySQL? for further information.
EDIT:
I'm going to assume you have a combo-box with different countries and possibly another with job titles and others.
If you create multiple tables then yes you would have to use multiple SQL querys, but the amount of data in the table would be flexible and deleting would be a one step process:
mysqli_query($link,"DELETE FROM Countries WHERE Name='India'");
With the json or array option you could have one table, and one column would be each combo-box. This would mean you only have to query the table once to populate the combo-boxes, but then you would have to decode the json strings and iterate through them also checking for null values for instance if countries had 50 entries but job titles only had 20. There would be some limitations on data amount as the "text" type only has a finite amount of length. (Possible, but a nightmare of code to manage)
You may have to query multiple times to populate the boxes, but I feel that the first method would be the most organized and flexible, unless I have mis-interpreted your database structure needs...
A third possible answer, though very different, could be to use AJAX to populate the combo-boxes from separate .txt files on the server, though editing them and removing or adding options to them through any way other than manually opening the file and typing in it or deleting it would be complex as well.
Unless you have some extra information at the level of the combo-box itself, just a simple table of combo-box items would be enough:
CREATE TABLE COMBO_BOX_ITEM (
COMBO_BOX_ID INT,
VALUE VARCHAR(255),
PRIMARY KEY (COMBO_BOX_ID, VALUE)
)
To get items of a given combo-box:
SELECT VALUE FROM COMBO_BOX_ITEM WHERE COMBO_BOX_ID = <whatever>
The nice thing about this query is that it can be satisfied by a simple range scan on the primary index. In fact, assuming the query optimizer of your DBMS is clever enough, the table heap is not touched at all, and you can eliminate this "unnecessary" heap by clustering the table (if your DBMS supports clustering). Physically, you'd end-up with just a single B-Tree representing the whole table.
Use a single table Countries and another for Job Descriptions setup like so:
Countries
ID | Name | JobsOffered | Jobs Available
_________________________________________
1 | India | 1,2,7,6,5 | 5,6
2 | China | 2,7,5, | 2,7
etc.
Job Descriptions
ID | Name | Description
___________________________________
1 | Shoe Maker | Makes shoes
2 | Computer Analyst | Analyzes computers
3 | Hotdog Cook | Cooks hotdogs well
Then you could query your database for the country and get the jobs that are available (and offered) then simply query the Job Description table for the names and display to the user which jobs are available. Then when one job is filled or is opened all you have to do is Update the contry table with the new jobID.
Does this help? (In this case you will need a separate table for each combo-box, as suggested, and you have referencing IDs for the jobs available)
I am very new to Access and I am working on a database and I need help coming up with a solution:
I am recording data from a bunch of asphalt laying crews. Each crew has a record with a field for production and equipment. Each crew has varying types of equipment and varying quantities of equipment. Therefore, I would need to create a new table for the type and quantity of equipment every time I enter a new record... can someone please help me come up with a solution?
You do not need a new table for each record, you just need a properly set up table. Let us say:
Crews table
CrewID
Location
Etc
CrewMembers table
MemberID
Etc
CrewEquipment table
CrewID
EquipmentID
DateIn
DateOut
Etc
Equipment table
EquipmentID
Details
Etc
You might like to read http://r937.com/relational.html
With the above set-up, you can have a Crew form with subforms for members and equipment. You can get an idea from this create form to add records in multiple tables
Creating new table everytime is not solution, you should clear some RDBMS concept like normalization first. Create separate table for
crew member (which include crew member id, his name, salary/wages
List item per hour) equipments (which include equipments id, operation cost per hour etc)
Shift (can be separated by date and shift time etc)
Then create proper relationship between tables and this way you can create proper relational database system. so finish some basic tutorial first then start development.
What would be the best way to design a mysql table, which can be filled with HTML (+PHP) form.
Actually I have this structure:
Table PRODUCT
ID | Ordernumber | Name | Desc | Price
Table PRODUCT_KIDS
ID | MasterProductID | Ordernumber | Price
The only difference between my 2 tables are Name and Desc.
The ADD HTML form looks like this:
DATA FOR PRODUCT
Ordernumber
Name
Desc
Price
DATA FOR PRODUCT_KIDS
Ordnernumber
Price
For some reasons, the customers want for example only 2 PRODUCT_KIDS without their MasterProduct. In this case I need the Name and the Description from the Master-Product.
My questions are the following:
Should I merge these two tables together? Is this the best way to search for something?
When I merge these 2 tables, should I save the Name & Desc for the PRODUCT_KIDS as well (for the example above)?
what would be the best way to design a mysql table which can be filled with HTML (+PHP) form.
Who cares? Contrary to popular believe, MySql is JUST ANOTHER relational database and PHP just another web scripting technology. The answer is the same whether you use mysql + php or oracle + java or sql server + asp.net.
The principles of relational database design apply to any relational database. As such, the question is not related to MySql and particularly not at all to PHP.
Table PRODUCT
Table PRODUCT_KIDS
This is a simplistic view on the topic that leaves out a lot of even legal items, such as possible international taxation, different shipping codes and their prices (not all items can be combined in one shipment) and for example customization of items in general - I remember writing a shop where PIPES where sold, in custom lengths ;) And some items requires separate shipping ;)
"The Data Model Resosource Book", Volume 1, discusses standard enterprise scnearios in great depth - including address management (not as simple as most people do it), accounting and.... the whole shop blabla (storage, inventory, pricing). BOTH (!) of your approaches are simplistic and would be totally illegal in my juristidciton because it would not take into acocunt legal requirments for properly tracking taxation on various products.
I can only suggest gtting it - they also go in great depth on some of the industry level particularities. For example ;) - Apparel. Make a shop for cloths and you go nuts on "variatns in size AND color for the same product". Your approach would result in a "shirt" possibly having 200 children (sizes * colors) ;)
I would suggest: back to the drawing board. With a good book ;) I personally loved reading this book - hm - a long time ago.