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.
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 have the following relationships:
order_products (1 or n) ———————— (1) orders (1) ————————— (1) transactions
... (1) (1)
price | |
qty | |
(1) (1)
users users
Should I leave 2 relationships to users table as above?
I intend to show the total order amount or get the transaction amount will query the order_products table. This is better than adding the amount field at 1 of two tables (or both) orders, transactions?.
Start by deciding which relationship exists in each case:
1-1 -- the two tables should probably be merged together.
1:many -- the "many" table has a column with the ids into the "one" table.
many:many -- This needs an extra table with 2 ids (one for each table).
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.
I need to record or match one or more rows in one table to one or more rows in another table. I think this works with a third table (a junction table), but not certain.
Not concerned about speed or anything fancy like that atm, just a reliable table design. The two important reporting elements here are:
being able to generate paycheque hours AND a list of tasks performed on same report
to tell who worked on each task (since the data may come in without individual hours (ie a team spent x number of hours on the task), we won't always be able to narrow down exactly how much each employee on a team spent on one task, we are fine with this limitation).
Here is an example:
"HOURS TABLE" records hours worked.
Fred and Joe each work 8 hours on day 1 - so this is two rows in the db
Frank worked 8 hours on day 2
"HOURS TABLE"
eeid hours junction
1 8 1
2 8 1
3 8 2
Second table records what was worked on (Called units table but actually want to record the hours to a task).
Day 1, Fred and Joe built a bench (12hrs), drove around (3hrs) and cleaned up the shop (1hr) - So this is three rows in the table "TASK TABLE"
Day 2, Marilyn spent 8 hours on the same bench, one row in "TASK TABLE"
"TASK TABLE"
ItemID hours junction
1 12 1
2 3 1
3 1 1
1 8 2
Third table is the "JUNCTION TABLE", serves no other purpose except to tie it all together, this is the junction table
"JUNCTION TABLE"
ID
1
2
Issues :
Fred and joe might be a team of 1 or a team of 10.
Multiple employees may work on the same things (like building a bench), and need to tie each row in the "TASK TABLE" to the row(s) in the "HOURS TABLE"
Not sure the junction table should just be a reference, wikipedia shows an example where it is actually storing data, but i don't think that would be appropriate here
I don't know how I will write the query to do my reports mostly because i have never used a junction table before, can't imagine it is that much harder.....
I suppose I could suggest that we force the employees to give separate time sheets, this would remove all of these challenges, as one record could record the hours per task and those records could be summed by day to get the daily hours. - Don't know how bad a junction table is to know if this should be suggested.
Many-to-many relationships in SQL require a JOIN table. Foreign key constraints can only model 1-to-many relationships, so you need one for each side.
Your requirements are confusing, but here's a simple example where one or more USER can be assigned to one or more UNIT:
create table user (
id int not null auto_increment,
primary key(id)
);
create table unit (
id int not null auto_increment,
primary key(id)
);
create table user_unit (
user_id int,
unit_id int,
primary key(user_id, unit_id),
foreign key user_id references user(id),
foreign key unit_id references unit(id)
);
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