3
Contributors
3
Replies
5
Views
4 Years
Discussion Span
Last Post by drjohn
0

It could be me, but I would tend to say that it is challenging to give you proper feedback without really knowing data that is being collected and the workflow(s) associated with it. Maybe someone else with expertise in SQL design could provide a better response.

0

@JorgeM

we're a small company that is doing on site calibratoins for tempreature, pressure and other sensors and issue certificates.

all i want to do is to implement a software that will ease the management of the massive and increasing data that we have.

i want to automate the issuing of certificates and keep their results in a mysql database.

Is that enough or so you need more clarification?

0

You have a table certificate with an attribute result_id and that appears to be a foreigh key from a table called result. But result only has a SINGLE attribute - result_id.

Why are you storing this value twice??? The table result looks totally redundant to me.

Also, you have department with many sections, and section has its id in the equipment table. But department ALSO has its id in the equipment table. You do not need the department_id in the equipment table, that data is accessable from the section id by querying the section table. So I would drop the one to many link between department and equipment, removing the department_id from equipment.

If a section was assigned to a different department, you'd have to go looking for all references to the section in equipment and change the department_id, wouldn't you.

Does an employ work in a section??? you might need a foreign key of section_id in employee.

How does a task relate to anything? Does a task involve several bits of equipoment being used perhaps? Should there be a link table task-equipment perhaps???

Edited by drjohn

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.