sambad wrote:
什麼程度的人會讀什麼...(恕刪)
拜託，
那些早就有電子檔了，
再說這種程度的東西，
我還真的沒印過，
印出來幾百頁浪費紙而已，
看再多也沒有實作重要。
的確是什麼程度的人會讀什麼程度的書，
拜託你去OTN上面看一下最新版到多少了吧，
雖然PL/SQL語法沒有什麼太大的變化，
但是有些Function是舊版沒有的。
panda0722 wrote:
骨灰級的東西還好意思...(恕刪)
因為我資料庫就是摸得比你久，
IBM-PC年代就在寫dBASE打工賺錢，
民國80年就開始寫Informix-4GL，
資料庫教科書裡面的flat file系統轉DBMS的歷史故事我全經歷過。
不論主機端還是PC端全都在碰，
而且還是由Coding一路做起，
幾乎軟體開發週期每個環節我都親手做過。
很多人只會拿著SQL雞毛當令箭，
弄了半天原來連基本程式語言能力都差到不行，
而且資料庫根本不是難在SQL怎麼寫，
在說SQL寫得好很難的根本還只在入門階段。
現在各種資料庫工具又簡單又容易上手，
連程式設計工具都可以自動除錯，
寫C還是寫SQL容易到我都懶得拿來說嘴，
那個叫基本能力就像你該認得ABC到Z全部的英文字母一樣基本。
看了半天你不像科班畢業的，
沒事請多看書多進修少來亂。
至於臉盆與馬桶，會用的人不怕它是臉盆還是馬桶，
只有半桶水的在才會執著在是臉盆還是馬桶，
而半桶水都不到的人卻只會跟著喊臉盆或馬桶。
公喵不帥, 母喵不愛. 公喵愈壞, 母喵愈愛. 不帥的公喵想要母喵愛, 就只好學壞.
panda0722 wrote:
我還以為你要拿COB...(恕刪)
真是程度低下！
沒SQL年代難不成就不能用電腦了？
那年代寫過程式才會深刻體會SQL有多好用，
更不怕SQL做不到的事情會沒辦法寫程式。
現在UI用什麼寫都可以，VB／C++／C＃／Java／ASP／PHP都好，什麼方便用什麼。
但是SQL抓出來的資料要在何處做其餘的運算與加工？
還是說你只會SQL，剩下SQL辦不到的資料加工全部兩手一攤？
資料加工還要看狀況來決定是不是要下SQL，
要不要用複雜資料結構要不要做什麼前置後置處理都有機會要寫程式，
不是兩手一攤什麼都靠SQL就可以解決。
寫系統更麻煩的是要看狀況，
不一定都是能用SQL就得用SQL。
還是說你的UI等級只低下到去設data source，剩下的就是Insert/Delete/Query/Update靠Data Object在做，連資料加工都不必？
你可以在前端UI跑資料加工也可以在後端主機部份跑資料加工，
要看系統安全性等級以及使用考量。
會計系統過帳在何處跑？Instance起在何處？在主機還在UI跑？
過帳難不成只靠SQL，蝦米程式碼都不必寫？
資料庫引擎掛在主機上，
過帳在主機端用Embedded SQL跑很正常。
看這形狀你只會拉拉UI，
處理資料萬一SQL做不來就兩手一攤是不。
你以為主機就起個資料庫engine然後啥事兒都不做，
全靠UI在做噢？
公喵不帥, 母喵不愛. 公喵愈壞, 母喵愈愛. 不帥的公喵想要母喵愛, 就只好學壞.
flanagan wrote:
也許您有您的堅持您有...(恕刪)
我從來都沒說過撈資料不要用撈資料的工具，
請聽清楚：該用什麼就該用什麼！
我本人寫SQL很多年，不但愛用它也推薦它。
但何時該用SQL何時該用AP，
這要看狀況，
根本不是你說用SQL能解就非得用SQL解。
還有那種說什麼收爛攤這種東西我本人絕口不會說，
因為我唯一收不了的攤是人的攤。
技術的問題靠著嚴密的流程控管很難累積到爛攤才要收。
累積成爛攤，那不是工程師的責任，是PM與SA的責任也有可能是公司開發流程的責任。
用人不明造成的爛攤是自己的責任，不是別人的問題。
我有把握用什麼人來寫程式，就有把握收掉他全部的攤。
之前處理半導廠的activity based costing，
由於整個製程前後要跑上百個工作站，
又會有merge/split/rework問題，
你要依據每片wafer跑過那些機台來算成本，
而且同個工作站還會因為時間不同當班的人不同所以成本也不同。
這整個生產資料就是會形成多層迴圈／網路結構。
若是純用SQL來跑，一天一張報表要用掉15萬乘上300到400平方不等的SELECT命令。
用LOOP跑SQL很炫對不？
還可以用程式碼產生SQL字串產生動態SQL來跑，
超炫但很瞎！
你要怎麼跑？用AP呀，SQL下一道，資料抓到Linked list跑下去比寫SQL還容易，沒人在怕LOOP式資料紀錄。
而且這種程式才顯得出OOP價值，
直接做物件Linked List模擬晶舟運作才叫又快又好懂又好寫。
對呀，有人會說都用SQL解是不？
還有另一個好玩的例子，
幫某金融業寫程式，
要拉出每個選擇權每日的理論價格來畫線圖，
使用者動態輸入參數我就得動態算出一狗票答案。
算它的理論價格要套Black-Scholes模型，
於是要做Accumulated Normal Distribution，
而且是每筆資料依據過去30天或不等（有人用90天）資料來推導。
用SQL來解嗎？可以呀，寫個Stored Procedure搭在SELECT命令裡多省事呀。
問題是選擇權公式沒有封閉解要用梯形法來解積分值耶，
把這玩意兒寫成stored procedure，
亂有成就感耶。
可惜雖然能用SQL解但是主機會忙到掛點，
不如SELECT row data進陣列再用AP解。
SQL很好用，但不能濫用，更不能拿著雞毛來當令箭來用。
尤其是Long transaction對某些敏感產業是無法忍受且會出問題的，
這種背景下見到有人捨去SQL而用AP解反倒是合理的選擇。
工具是該用什麼就該用什麼，
我從不認為C還是SQL誰是王道，
能合宜的用它才是正解。
公喵不帥, 母喵不愛. 公喵愈壞, 母喵愈愛. 不帥的公喵想要母喵愛, 就只好學壞.
sambad wrote:
我從來都沒說過撈資料...(恕刪)
小弟5年前也停留在ap獨大的階段
一直到摸到十億筆以上的db以後才脫離單筆資料的思考邏輯
舉個例子
對一個1千萬筆的資料庫您要如何處理？
一般的select掛掉的機會非常高
所以對大資料量的處理都是用迴圈into到次資料表
做群集處理以後 在做下一步處理
至於您說的ap 小弟曾經把php asp 整個寫到資料庫去
但是美編的css失效只好把部分又抽出來
c＃只能套部分的用法
但是會大量減少code的量
不過維護就不是一般的rd有辦法維護了
小弟也有3小時內用sql處理掉一家醫院30年的預算決算
說這些只是舉個例子並不是在說明sql有多強或啥都可以做
只是開發觀念不同
給您參考
flanagan wrote:
小弟5年前也停留在a...(恕刪)
我一直強調，該用什麼就該用什麼，絕對沒有誰對誰錯。
我是不論進Cursor還是進View，能快速解就用SQL解。
在這領域呆了廿年，
我認為程式與SQL是相輔相成的東西，
不是說用誰才是王道。
能否解決問題，未來是否好維護，或者是策略性要讓它難以維護，都有它的考量。
之前做半導廠的case，生產主資料表一天以十五萬筆資料增加。
雖說用cache方式讓master table只保持最近一年份資料，但是也有個五六千萬筆資料。
印象中當時用Informix不常遇到select掛掉，您說的問題我可能要看到才知道。
EDA（Engineering Data for Analysis）資料倒是比較大，一天差不多要一百多萬筆，但我們有專門的機器做replication。我還有寫一個Windows版DBAccess給工程師用，似乎也沒太大問題。
最近由於RAM和白開水一樣便宜，所以主記憶體一次可以塞個幾億筆資料不成問題，SQL掛掉機率大減。
應用實例與環境要見到才知道，真的沒有誰對誰錯。
程式寫到當掉，有時還真不是程式員的問題。
舉個超好玩例子，以前寫Turbo C，我遇過一個case，只要在某兩行程式碼之間加一行空白，程式就不會當掉，否則就一定死當。你說誰對誰錯？
這年頭有經驗的程式員SQL下到當掉真的不常見，你的case我還真的得見到才有把握。
講句良心話，你也算有點程度還能聊點東西，我是把你當朋友來聊天，要是有口氣不善請多包涵。
公喵不帥, 母喵不愛. 公喵愈壞, 母喵愈愛. 不帥的公喵想要母喵愛, 就只好學壞.
內文搜尋
從 APP 打開
X