I need to establish a relationship in an existing database containing 3 tables for 3 measurement devices A, B, C that will populate these 3 tables independently:
[table1] [table2] [table3]
id id id
mesA_1 mesB_1 mesC_1
mesA_2 mesB_2 mesC_2
Each sample is assigned a unique id, and that's how we can associates the 3 sets of measurements that correspond to the same sample.
So I have to create the 3 tables and the relationship between the three id keys.
In the end I want to be able to query the database from Excel to display in a single line the measurements of the 3 devices.
I followed tutorials but most of the time they're for 2 tables and not 3. Basically I set every id key as PRIMARY but then I do not know if the relationship is two-way or not, if must chain the 3 tables or define a master and two childs. In short I'm clueless.
Related
Are there big disadvantages (maybe in query speed etc.) of using only ONE combined lookup table (mySQL database) to store "links" between tables over having individual lookup tables? I am asking because in my project scenario I would end up with over a hundred individual lookup tables, which I assume will be a lot of work to setup and maintain. But to make an easier example here is a simplified scenario between only 4 tables:
Table: teacher
teacherID
name
1
Mr. X
2
Mrs. Y
Table: student
studentID
name
4
Tom
5
Chris
Table: class
classID
name
7
Class A
8
Class B
Table: languageSpoken
languageSpokenID
name
10
English
11
German
======================= INDIVIDUAL LOOKUP TABLES ==========================
Table: student_teacher
studentID
teacherID
4
1
5
1
Table: student_class
studentID
classID
4
7
5
8
Table: student_languageSpoken
studentID
languageSpokenID
4
10
4
11
====== VS ONE COMBINED LOOKUP TABLE (with one helper table) =====
helper table: allTables
tableID
name
1
teacher
2
student
3
class
4
languageSpoken
table: lookupTable
table_A
ID_A
table_B
ID_B
1
1
2
4
1
1
2
5
3
7
2
4
3
8
2
5
Your 2nd lookup schema is absolutely unuseful.
You refer to a table by its name/index. But you cannot use this relation directly (tablename cannot be parametrized), you need to build conditional joining expression or use dynamic SQL. This is slower.
Your lookup table is reversable, i.e. the same reference may be written by 2 ways. Of course, you may add CHECK constraint like CHECK table_A < table_B (additionally it avoids self-references), but this again degrades the performance.
Your lookup does not prevent non-existent relations (for example, class and language are not related but nothing prevents to create a row for such relation). Again, additional constraint and decreased performance.
There are more disadvantages... but I'm too lazy to list them all.
Another very important point: Foreign key constraints assuring referential integrity cannot be used in the "combined lookup" approach. They needed to be simulated by complex and error prone triggers. Overall the "combined lookup" approach is just a horrible idea. – sticky bit
There is a rule - non-relational relations must be separated.
In the 1st scheme - does a student may study in more than one class at the same time? If not then you do not need in student_class lookup table, and class_id is an attribute in student table.
Lookup tables are usually static so there shouldn't be much maintenance overhead. If you update the lookup data, however, now have to manage the life cycle of a subset of rows of your single lookup table which may get tricky opposed to just truncating a table when new data becomes available. Where I would be careful if your lookup table have different schemas with columns have to be null as they apply to a given "type" of row. You may not be able to implement the right foreign keys. If you happen to use the wrong id, you would get a nonsensical value. Those help you keep your data consistent (in production systems). If this is school project, especially a database class, you will be dinged for not using textbook normalization.
I need help to design a table for Restaurant Point of Sales System particularly in merging and unmerging restaurants table.
For example, i want to merge tables 1-3 as Table 1,
-Table 1
-Table 2
-Table 3
Table 4
Table 5
Then it would be something like this,
Table 1
-Table 1
-Table 2
-Table 3
Table 4
Table 5
After a transaction the tables can be unmerge. Anyone who has a solution to this?
To expand on what zerkms suggests, you will want a two-tiered system to support this approach. Link table information (server, order, timing, etc) to a Seating. Seating will have a one-to-many relationship with a Table relation.
When a guest is assigned to a single table, one Table will be linked to one Seating. If a group of guests is assigned to multiple tables, multiple Tables will be linked to a single Seating.
When a group of guests leaves, unlink their Tables from their Seating. To count unused tables, simply COUNT entries from Table.
- Seating 1
- Table 1
- Seating 2
- Table 2
- Table 3
- Table 4
Note: Table entries will be static for the lifetime of the restaurant (unless more physical tables are added). Seating entries should be dynamically created and removed as necessary.
I got three tables Orders (1) & OrdersLinking (2) & Products (3).
1 and 3 have a m:n relation through 2 as linking table.
How would I make a form that can create a new entry in table 1 and 3. While there are no existing entrys in 2 due to the missing IDs (not created yet).
Thanks in advance!
Is it possible to have the ID of the next generated row (across 2 tables) be unique?
I have 4 tables:
1 for teachers
1 for students
1 for projects
1 for relations
The relations table has 3 foreign keys.
One refers to teachers IDs, one to students IDs and the other to projects IDs
Since a project can be related to teachers but also students at the same time, how do I make sure that a new created teacher or student won't have an ID already used by the other type of account?
If I can do that, then the relations table would have only 3 columns:
ID, project_ID and related_to(ID)
If not, I would have to add a 4th row indicating the type of account that it relates to (student or teacher).
Thanks for your help!
Regarding the difference between account types:
I have to translate this exact same situation to another project of mine in which the first two tables are completely different. That's why I don't bother to merge the students and teachers tables here.
You do not need to have unique values between the student and teacher tables because the relation table has separate fields for each relationship, so there is no conflict.
However, this is not the right way to do things. You need two relation tables, teacher_project and student_project. Alternatively, depending on the unique data that's different between teachers and students, you could have a single person table and a single relationship, which is probably closer to the real world anyway.
I think you can identify the teachers begin with 1 ,incremental 2; the students begin with 2 ,incremental 2.By this way,odd number refers to teacher while even number refers to student.No conflict will happen.
I have a bunch of lookup tables:
Religion
Country
City
nationality
Currency
etc... approx 80-100 lookup tables.
Now I have system tables where i am centralizing all the fields and values so i can ID all fields, centralize them for reporting and add multi-language to my lookups. So these are tables like:
Form (all forms on system)
Field (all fields on system)
Value (all values for all fields on system)
Form_Field_value (mapping them together)
Translation (maps value and field to multi language)
but the question is how to get all the 80-100 tables data into these Field / Value tables? So it will be like this:
Field table:
id 1 Natioality
id 2 Country
1d 3 city
...
Value table
1d 1 american
id 2 chinese
id 3 rusian
...
field_value
id 1, field_id1, value_id1
id 2, field_id1, value_id2
id 3, field_id1, value_id3
...
Ofcourse i can manually do it but then it defeats the purpose of having those lookup tables. So ideal is to keep these tables in sync. next question is which tables to use for user forms? The lookup tables or the form_fields table?
union select http://dev.mysql.com/doc/refman/5.0/en/union.html