is this ok, just thinking if I can make any improvements on it, or can anyone forsee or predict any problems that may occur with the database design for a simple restaurant order system.

TYPE ( typeName* , typeUnique )

ITEM ( itemID* , typeName , itemName, itemAvailableSizes, itemAvailablePrices)

ORDER_ITEM ( orderItemID*, orderNo , itemID , orderItemQty, orderItemSize, orderItemPrice)

ORDER ( orderNo* , customerID , orderTime, orderDate, readyFor, timeGiven, subTotal, discount, grandTotal, cashTendered, changeDue, orderType, NumberOfItems)

CUSTOMER ( customerID* , name, phoneNo, address, postcode )

I guess that the asterisk indicates a primary key... So what's the other field?

Is there any need for you to prefix fields in the orders table with the word "order"?

Order date and order time appear to be separated... What datatype were you going to use for each field? Generally a single datetime field should sort you out. Do you need to store the grand total, considering it is just a calculation based on the other information available to you? Some may consider this redundant.

Same goes for number of items.

What's an order type? Are you using the same type table for both item and order types?

yes * is primary key, yeah I got the prefix part, i was in a rush thats why i didnt prefix it. Not in terms of syntax, but is it correct as a relational database.

orderType can have one of two values, pick-up or delivery. type table has type, meaning Drinks, Main Meals, desserts.

what you may consider changing is the orderitme tabels

they are a couple of things you can looks at.. does the homework assignment allow the same product to be ordered more than once... if not make porderid & productID the primary key

alternativley you coudl ook at having orderitemno as an intger or byte filed ranging from 1......whatever.. and make orderIF & itemNo the PK.

I wouldn't normally expect order time and order date separate items.. but I suppose it depends on the db this is being implemented in, most dbs these days seem to support a composite date and time datatype

I don't think you need numberofitems, as it can be derived from the orderitems table

I can't see any table identifying products

but on the whole looks OK for now

item table is equivalent to a product table. yes I just used a very bad name lol. yes item holds data of a product i.e. price etc.