兩年程式設計師的感悟，SQL才是重點，JAVA無所謂。

scf37發表於2009-05-29
程式設計師SQLJava
我不是噴子，這只是真實的感受，其中也包含著很多無奈。。。
JAVA是我第一門掌握的語言，可以說是我在程式設計語言上的母語。也正是如此，我的設計思路從一開始就傾向於OO。已經習慣於把業務場景抽象為object之間的互動，一直以來資料庫僅被我作為持久化資料的解決方案之一來看待（其實簡單應用的話，格式合理的檔案作為持久化也未嘗不可）。換句話講，總是先有應用程式物件模型，再有配套的持久化方案。
然而上班以後才發現，現實完全不需要這樣。業務被化解為神聖的表，實體表，引用表，連結表。整個系統非常靈活，所有的程式配置也全部在表裡，還有專門的表來記錄表和表之間的join關係和一些預先寫好的sql子句。真是表中有程式，程式在表中。
JAVA需要做什麼呢？對，拼接SQL。程式碼再噁心也沒關係，而且只要程式導向，完全不必擔心有效能問題，要知道應用程式的響應時間是納秒級的，而資料庫的相應時間是毫秒級的。萬一很慢，那肯定只是你SQL沒寫好。什麼靈活性更是沒意義，客戶都是外行。只要找個留學歸來，擅長溝通，像模像樣的客服，耐心給他講道理：“看似簡單的修改，其實我們要增加表，增加欄位。。。”，首付都給了，為那麼個小修改的成本可能另起爐灶嗎？反過來講，就算你OO厲害，別人程式一改一週，你的程式半天搞定，也只是給專案經理認為是你的改動本身簡單，別人的複雜。再退一萬步講，就算客戶丟了，那也是客服的事情，銷售或者財務出身的老闆完全不會把這些怪罪到你頭上。
JAVA說完了，回頭看看SQL。資料越來越多，系統越來越慢。起初毫秒級響應的操作，慢慢變成秒級，到了分鐘級客戶就會來抱怨了。這個時候如果你SQL不錯就可以自告奮勇去調優，很容易就能發現很多初級錯誤。簡單改改，再最佳化下索引，效果立竿見影。立刻領導對你讚賞有加，認為這就是技術的力量。。。

我真的很無奈，以上講的也多少有些極端，其實領導也曾稱讚我的OO思想很好，程式碼簡潔、明晰。
只是有時我從一個旁觀者的角度來看這個問題。同樣能滿足一個需求的前提下，兩種實現的差距果真有我們設想的這麼大嗎？

[該貼被scf37於2009-05-29 14:18修改過]

相關文章