回覆 39# snoopy11hk


唔該哂 ching, 有機會真係要學下 Oracle 既 syntax.   

因為我目上面 #20 樓主講話用 rownum, 我跟住都用番 rownum (死, 睇番上面, 原來我打左 recnum, 唔好意思, 希望你知道我係想講乜.)
如果 rowid 至係 record insert 既 order, 咁就用 rowid 代替.

Oracle group 果陣 select 既野一都要 group 度出現?  呢樣真係唔知添.  咁條 sub-query 都唔成立了.
唔可用到 group 既特性, 就要寫多少少了.  睇下點樣可以一句過先, 唔用 group, 就要 sub-query 做手腳.

但係你果句做 sorting 又有問題, 否則唔用 input_date 改成 rowid 就得出結果.    始終接受唔到為左 min 去做 sorting 呢樣咁有破壞性既 SQL.

TOP

#8應該冇問題
lulufish 發表於 2016-3-31 23:17



句法無問題, 針對呢題既答案或者都無問題, 但本身存在問題.
唔係講笑既, 應該要避免犯呢D錯, 後果可大可小.

TOP

回覆 39# snoopy11hk



開始明白你點解話要 min, min, min 佢地了.
忽然有個想法, 因為 having 既結果係 unique record, group 左都係一條, SELECT 果下加個最簡單既 aggregate function (e.g min) 比佢唔知得唔得.

咁樣做有 D 畫蛇添足, 明明得一條 row, 但就叫佢 min(x) 之類, 總係睇落怪怪地, 同埋會浪費左D資源 (一條 row 做 min, 佢都應該照 search).  就算出到答案, 都唔係咁好.

不過, 我都想知 Oracle 既 syntax 受唔受?

TOP

回覆  snoopy11hk


唔好意思, 原來 #8 係你提供既, 我 miss 左, 仲成日叫你比 sample 我, 呢樣係我錯.
見 ...
Super169 發表於 2016-4-1 00:06


1, 2/input_date 唔 unique, 答案未必 deterministic, 可以 random 咁 A or B
呢個問題要交番去 design db果個,
要 deterministic 的可以用 rowid/ primary key

當然需唔需要就由樓主的DBA 決定

3/ Performance 呢家野你少擔心好了
連 SQL 都未行得郁你擔心點 改好過了

4/ 睇黎你唔明 analytic function 做的野
而家個問題係要揾第一條, 係要揾哂 related 的先知邊條係第一條
以 performance 黎講係無得慳

TOP

本帖最後由 snoopy11hk 於 2016-4-1 00:28 編輯
回覆  snoopy11hk



開始明白你點解話要 min, min, min 佢地了.
忽然有個想法, 因為 having 既結果係 uni ...
Super169 發表於 2016-4-1 00:23


好大機會 compile 行唔到, 又有機會 runtime error 出黎, 又有機會無病無痛
不過多數都 compile 唔到, 好少時間 runtime error/ 無 error 出

係, min, max 佢地實在解唔通, 只可以話係 dirty tricks, 個人實在不敢荀同

TOP

回覆  snoopy11hk


唔該哂 ching, 有機會真係要學下 Oracle 既 syntax.   

因為我目上面 #20 樓主講話 ...
Super169 發表於 2016-4-1 00:15



    row id 係 row's physical id
呢個問題要睇個 table 係咪 append 入去定 有 specific sequence 咁 insert
當然我只係好簡單左咁 assume 係 append 落去

TOP

唔理 performance, 最醜惡可以咁寫 (即係之前 #25 講搵無人細過你既做法) ...

SELECT *
  FROM <table> a
WHERE NOT EXISTS (SELECT 0
                     FROM <table> b
                                        WHERE a.account_no = b.account_no
                                          AND a.rowid > b.rowid)

呢下真係好睇  optimizer 識唔識化成 group 去做, 否則會有好大既 performance issue.

TOP

本帖最後由 snoopy11hk 於 2016-4-1 00:37 編輯
唔理 performance, 最醜惡可以咁寫 (即係之前 #25 講搵無人細過你既做法) ...

SELECT *
  FROM  a
WHERE  ...
Super169 發表於 2016-4-1 00:31

同我的諗法唔同之處係我唔覺得要做個 Anti Join (Not Exists)
因為 anti join 都係 semi join
我只係需要一個 sorting 去 cross reference 上下面的 row 入面的資料
除非個 table 太大, 做一次 window sort 貴過 anti join 好多
我唔會特別用呢條

TOP

同我的諗法唔同之處係我唔覺得要做個 Anti Join (Not Exists)
因為 anti join 都係 semi join
我只係需要 ...
snoopy11hk 發表於 2016-4-1 00:35


我都講左, 我果句係有 performance issue 既.  係唔理 performance 寫出黎.
同你果句都係, 做到答案, 唔代表就係好.
分別只係在於,寫既人知唔知問題所在.

TOP

1, 2/input_date 唔 unique, 答案未必 deterministic, 可以 random 咁 A or B
呢個問題要交番去 design d ...
snoopy11hk 發表於 2016-4-1 00:24



1/2: 夠資料就做到, 唔夠就要答做唔到.  唔好意思, 好難接在不確定情況下, 是旦比一條人都叫答案.
     我再三講過, 唔應該睇住答案做野.  你有咁既習慣, 我無野講.
         你之前講句果野, 真係無錯架, 希望你唔好只係講完就算: "就算咁好彩無錯, 都唔代表思考方式正確."  

3: 家陣講緊你果句 SQL, 我以為你試過 work 既, 所以至諗 performance.  

4: 搵第一條, 同要 sort 哂既分別都唔知?  無得慳? 唔係呀?  你講真定講笑架?
   你試下寫段 code, 比個 array 你, 搵最細果條出黎, 同先排哂全部 record, 再搵第一條出黎, 睇下有幾大分別.

TOP