※ 引述《grence (多想兩分鐘 = =")》之銘言：
: : 影片代號 流水代號 影片名稱
: : A01 1 神鬼奇航
: : A01 2 神鬼奇航
: : A01 3 神鬼奇航
: : =-=============================================================
: : 影片代號 影片名稱 庫存
: : A01 神鬼奇航 100
: : A02 命運好好完 10
: 這兩種存法…我覺得第一種可能比較有用
: 第一個schema要知道庫存量可以 count(*) group by moveName
: 但第二種推不回第一種，無法區分每一片現在的狀況....希望這樣說有人懂
第3種也是一種想法
A01 神鬼奇航
A02 神鬼奇航
A03 神鬼奇航
A04 命運好好完
A05 命運好好完
A06 命運好好完
情況一比較尬尷
(A01,1) 決定 '神鬼奇航'
但是 1 又不是 key，被弄的人不像人，鬼不像鬼它情何以堪 @"@
: : -----------------------------------------------------------------------
: : 最後,資料庫設計沒有對與錯,完全和商業邏輯規則有關
: : 但請記得,商業規則也不是完全一定就正確,轉成電腦化有電腦化的做法與限制
: : 我很常改廠商的規格咧...因為他的規則對資料庫很難維護,我是拒絕設計的
: 推這段。商業邏輯要比程式邏輯麻煩許多。
: 尤其是進銷存之類的程式，這類程式通常都是加加減減…國小數學，簡單，
: 寫程式只是幾個小時的事，但是確認需求、搞清楚遊戲規則大概是好幾個禮拜的事。
: 好像有問 php的書，其實大同小異
: html的<form>標籤、通常還會用到<table>
: php 的 SESSION、取得表單傳來的值
: mysql.phpmyadmin....僅要求能用就好基本上是不用書的，頂多再加個 SQL語法
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.231.50.130