Student
ID|long uint
Name|vchar

Order(每日時限後建立次日初始表)
ID|long uint
Student_id|long int(FK)
Order_type|byte(0、1、2、3)
Date|datetime

Order_type:0不訂、1雞腿、2排骨、3皆可
不過這個我會用程式語言去分配，不會純用SQL去做，畢竟我SQL真的不是很熟。
先從全部學生扣除不訂的學生，除以2，得到平均便當數
看是雞腿還是排骨超過平均數，把皆可的加在少的。並且update Order_type
都沒超過就先:

select * from "Order" where Order_type = 1 order by Random() limit (平均-雞腿)

並且把這些都update成雞腿，剩下皆可的就排骨

不是好辦法，但是如果要彈性一點的好像都會很複雜。

改題目就改答案

CREATE TABLE bdorder
(
studentno varchar(10) KEY,
choice varchar(02),
orderdate datetime
);


REPLACE INTO bdorder VALUES ('ST001', 'CL', '2021-11-25');/*訂雞腿*/
REPLACE INTO bdorder VALUES ('ST002', 'PB', '2021-11-25');/*訂排骨*/
REPLACE INTO bdorder VALUES ('ST003', 'PB', '2021-11-25');/*訂排骨*/
REPLACE INTO bdorder VALUES ('ST004', 'LP', '2021-11-25');/*兩個我都要*/
REPLACE INTO bdorder VALUES ('ST005', 'LP', '2021-11-25');/*兩個我都要*/
REPLACE INTO bdorder VALUES ('ST006', 'LP', '2021-11-25');/*兩個我都要*/

REPLACE INTO bdorder VALUES ('ST001', 'CL', '2021-11-26');/*訂雞腿*/
REPLACE INTO bdorder VALUES ('ST002', 'PB', '2021-11-26');/*訂排骨*/
REPLACE INTO bdorder VALUES ('ST003', 'LP', '2021-11-26');/*訂排骨*/

/* 統計要吃雞腿的 */
SELECT count(*) FROM bdorder WHERE orderdate=CURDATE() AND choice='CL';

/* 統計要吃排骨的 */
SELECT count(*) FROM bdorder WHERE orderdate=CURDATE() AND choice='PB';

/* 統計要吃兩個的 */
SELECT count(*) FROM bdorder WHERE orderdate=CURDATE() AND choice='LP';

(1)要能讓同學們可以方便使用學號來登入,選擇品項.

我想登入在本題不是重點

(2)要能方便紀錄選項.

一個學生一個欄位，超方便

(3)會有兩種均可的選項,是為了方便後續可以調整盡量將
當日雞腿與排骨總數量趨近,以避免影響供餐.但是在此
階段先不用考慮後續調整的方式,只需紀錄選項即可.

已定義代碼表示此種情形，就是 LP

(4)只需考慮當日.

每筆都有「下訂日期」，只有下訂日期=CURDATE()為當日

(5)在截止時間前,同學們是可以修改個人選擇品項的,只需考慮個人,
不需要考慮班級的情況.

不用你說，我壓根兒就不打算要考慮

(6)因為是只考慮當日的情況,加上所有的人員都是校內同學,所以系統
可以在每日初始時,透過學生名單,建立初始的情況.

我大概知道您在暗示什麼，不過我不會上當的

(7)初始情況的選項,就是都沒有選擇,也就是不吃.

只有「下訂日期」=CURDATE() 的才算數，其他都管他去餓肚子

(8)一個人只能訂一個便當.價錢也是一樣的.所以不用紀錄數量價格.

不用記錄的規格最棒了

就題目而言, 在不考量地址客戶的情況下
基本的欄位如下

訂單號 A便當數 B便當數

這是看到題目最直覺的處理方式。但不考量未來性。

但就正規化而言來說。

我會用至少3張表，也就是常見的訂單系統。

訂單表:訂單ID,訂單號..........(其它依需求增加)
訂單商品表:訂單ID(index),商品ID(index),數量
商品表:商品ID,商品名稱(便當名)

當然以上只單純針對訂單的欄位為主，還未考量價格、特價、客戶等等相關資料。

---學生資料表---
studentId key 學生編號
studentName 學生姓名
password 密碼

---訂單主檔---
ordersId key 訂單編號
studentId key 學生編號
termdate 訂單日期
termtime 訂單時間
qty 訂單總數量
memo 訂單備註
flag 狀態 0 為初始正常 -1 作廢 1 不可改單

---訂單明細---
ordersId key 訂單編號
studentId key 學生編號
itemNo key 項目
materialID 商品編號
qty 訂單數量
flag 0 為初始正常 -1 作廢 1 不可改單

---商品主檔---
materialID key 商品編號
materialName 商品名稱

大致上是這樣
如果要改單看原單要不要保留改flag -1 重新在新增一筆

這是我四年前用ASP.net+jQuery寫的，想在公司裡用
(全公司300多人每天光訂便當的事就人仰馬翻)
但.......之後熊貓興起，這個訂便當系統就.....被淹沒

人員資料接入公司AD，所以不用建訂購人的資料

(沒想到還能working耶，現在執行起來，超柔順....)

帳密 TABLE :

學號
姓名
密碼

訂單容許訂購數量 TABLE :

供應商 : A (雞腿)、B (排骨)
數量
優先權 : 先滿足 A 或是 B

訂單 TABLE :

日期
學號
選項 : 空白 (不訂)、A (雞腿)、B (排骨)、C (兩種均可)
選項(調整) : 處理兩種均可(截止後由系統統計數量後填入 A 或 B，並且不超過訂單容許訂購數量)
截止 : Y/N

1.廠商油鍋有限 : 先訂先贏，用【訂單容許訂購數量】控制訂單(雞腿/排骨)上限
2.避免某日過於集中一種選項 : 用【選項(調整)】
3.數量統計 = 選項(A/B) + 【選項(調整)】(A/B)

若是推派我來設計的話，我絶不允許【兩種皆可】這個選項，尤其是女同學！

我吃了太多虧了，每回我問太座，中午吃什麼？當她回答【都可以】的時候，我就知道大禍臨頭啦。

我來設計絕不接受可以複選或是兩者皆可或是不吃這幾種選項
對於選擇障礙的人來說，那是一大考驗
但我覺得可以推出推薦便當 每周輪流我覺得這個很棒