Ok, before I keep chasing my tail and without signing up for 4 years of academics on db's...here's what I want to achieve:

 

Food Ordering System

==================

 

1) Cashier/Order screen/layout

 

2) Food Prep screen/layout

 

3) Delivery screen/layout

 

Which would work like this: Order is taken, THEN said order is displayed/formatted for Prep, THEN/IF an Order is a Delivery it is displayed/formatted for that screen.

(BTW, these 3 stations will be iPad-driven with, I believe at this point, an mac mini for the 'base')

 

So what's my question...?

 

I'd like seasoned views on how to breakdown the data into tables/relationships that 'make sense'.  I've started over several times and get lost in the relationships needed (equals brain hurt...no pain, no gain I suppose).

 

I have a rough mockups (my primary talent is artistic/graphic design) of the order system screens/layouts attached...

 

For example, I made a table for FOOD and a separate one for DRINKS...thinking that that would make it quicker to index/search if I had more tables instead of one all encompassing table of FOOD AND DRINKS combined.  Is this the right thinking?  Then I gave each of those ItemID...am I on the right track?  I've included a copy of db WITHOUT any relationships...

Order Copy_20130108.fmp12.zip

Edited January 8, 201313 yr by happyshotdogs

Tables are cheap, but I don't think there's much if anything to be gained with separate food and drinks tables. They are both "products" that would be used in the same way in your order system. I'd keep them in the same table, and add a "category" or "type" field to distinguish them.

Thanks, Fitch...ok, so probably the same with Customers and Vendors, too?  Just one table, but use a "type" field (c or v)...

 

Then I'm still trying to wrap my head around the use of Layouts, Portals and Scripts...and I tend to be a visual learner (I haven't found many 'good' how to's on youtube yet...).

 

For instance, the process of taking an ORDER, I'd like it to be broken into smaller layouts (for ease of the UX) to achieve a complete order:

 

1) "Type of order..." [Order::OrderTYPE (radio buttons)], [Order::OrderTIME_IN (auto-timestamp)], THEN goes to layout based on radio button choice; it would be nice if this happened automatically after a validation dialog "Delivery?" [OK, CANCEL]

 

2a) WALKUP layout...NO customer info needed, just Order# [Order::OrderID] and person can input actual MENU ITEMS...

2b) DELIVERY layout...customer info is taken, THEN proceeds to layout to input MENU ITEMS..

2c) PICKUP layout...customer info is taken, but ONLY name/phone#, THEN proceeds to layout to input MENU ITEMS...

 

So I'm trying to understand HOW does the input stay in the same record when I'm changing layouts and using different tables for the info?  Do I need ONE table using Portals from the all the other tables used or...?  I appreciate having patience in my ignorance.

 

Once I "get it", I should be good to go

 

Thanks!