Zi 字媒體

內含C語言、java、資料庫新手錯誤集錦還記得你剛學C語言的情形嗎？當初看上他，可能是因為入門學的，可能是因為他既強大，又靈活；不管因為什麼原因，你都入了C語言這個坑，現在回想起來，剛入坑那會，是不是也犯過一些初級的錯誤呢？比如說：1、標識符不區分大小寫C語言習慣上，符號常量名用大寫，變數名用小寫表示，以增加可讀性；2、忽略了變數的類型，進行了不合法的運算%是求余運算，得到a/b的整餘數。整型變數a和b可以進行求余運算，而實型變數則不允許進行「求余」運算。3、將字元常量與字元串常量混淆char c;c="a";在這裡就混淆了字元常量與字元串常量，字元常量是由一對單引號括起來的單個字元，字元串常量是一對雙引號括起來的字元序列。C規定以「\」作字元串結束標誌，它是由系統自動加上的，所以字元串「a」實際上包含兩個字元：『a'和『\'，而把它賦給一個字元變數是不行的。4、忽略了「=」與「==」的區別。在許多高級語言中，用「=」符號作為關係運算符「等於」。如在BASIC程序中可以寫if (a=3) then …但C語言中，「=」是賦值運算符，「==」是關係運算符。如：if (a==3) a=b;前者是進行比較，a是否和3相等，後者表示如果a和3相等，把b值賦給a。由於習慣問題，初學者往往會犯這樣的錯誤。5、該加分號的時候忘記加，不該加的時候又加上了少加分號的情況：多加分號的情況：最重要的是，在編輯器報錯時，你卻查不到錯誤，最後發現把;寫成了；同比，雖然java和C是不一樣的語言，但是我們可以看到，新手期犯的錯還都差不多，比如說：1、不區分大小寫的情況變數money和Money，雖然是一個單詞，但是不一樣的，一定要記得；2、將數組轉化為列表將數組轉化為一個列表時，程序員們經常這樣做：3、判斷一個數組是否包含一個值程序員們經常這樣做：4、一個等號和兩個等號的不同在Java程序中，一個等號是賦值操作符，而兩個等號則是比較操作符。在java新手的程序中經常出現這樣的代碼：5、空引用的錯誤這類錯誤也是最令人頭疼的，屬於邏輯性錯誤，編譯器可以正常編譯，但是在某種情況下執行出錯，出錯信息是java.lang.NullPointerException。這是由於在對象的引用沒有被初始化的情況下而調用這個對象的屬性或者方法而造成的，比如下面的例子：說完語言，我們再來看看資料庫新手們，都常犯什麼錯誤：1、Storing images儲存圖片資料庫里不應該放圖片。你可以做的事情並不代表你就應該去做。圖片會佔用資料庫里相當大的空間，吃掉不必要的IO資源從而拖慢應用。這個錯誤最常出現的情況，就是新人將圖片用base64編碼，然後將其儲存在很大的text/blob欄位當中。 2、Limit/Offset分頁在很多應用中都非常常見。從你開始學習SQL，（你就該知道）最直接的分頁方法就是先用ORDER BY對資料庫的一些列進行排序，然後LIMIT返回的結果數，對除第一頁外的每一頁使用OFFSET。這看起來很符合邏輯，直到你處理中等規模應用時才意識到：它對資料庫施加的負載是非常痛苦的。它具有不確定性，記錄應該隨著用戶翻頁而改變。 3、用整數做primary key在創建primary key的時候，幾乎所有的ORM（Object Relational Mapping對象關係映射）的默認做法都是創建一個串列欄位，它是按順序自動生成的，然後你就可以用它（這些自動生成的數字）作為你的primary key。在管理員看來，這是非常直觀的，因為可以由用戶1到用戶2這樣依次查看。對大多數的應用來說，這種做法通常是不錯的。但是隨著這些整數primary key不斷變大，你很快就會意識到處理他們會讓人筋疲力盡。對於大規模系統，這是很不理想的處理方法。此外，你還會依賴生成這些key的那個系統，在你必須要擴大規模的時候，會非常痛苦。更好的解決辦法是從一開始就利用好UUID（Universally Unique Identifier通用唯一識別碼）的優勢。 4、新列中的默認值無論你做這個工作有多久，都不會一次就創建出一個完美的schema。最好是將資料庫schema視為一個持續演化的文檔。不幸的是：向資料庫中添加一列是件很容易的事，這也就意味著在添加列的時候把工作搞砸同樣很容易。默認情況下，如果你新添加了一列，通常是允許有NULL值的。這個操作速度很快，但大多數應用實際上不太想讓他們的數據里有null值，他們會想要設置默認值。如果你在表裡添加設置了默認值的新列，會對這張表觸發一次完全的重寫。注意：這對應用中的任何（數據量）很大的表都非常不利。（正確的方法）恰恰相反，最好是先允許null值存在，這樣操作就是即時的，接下來再設置默認值，再用後台進程去回溯更新數據。 5、過度標準化開始學習資料庫的標準化的時候，（標準化）感覺就像是很正確的事。你創建了一個posts的表，裡面包含authors，每篇文章（post）都屬於一個條目（category），所以你又創建了一個categories的表，然後再創建一個把它們倆join在一起的表，post_categories。從根本上來說，這樣做標準化也沒什麼原則上的錯誤，但是某種程度上，標準化的收益正在遞減。在上述實例中，categories可以簡單地作為post里的一個varchar欄位。標準化是件很有意義的工作，但是每次處理包含多對多關係的表時都要深思熟慮，想想你是不是真的需要在關係的兩邊都各用一個單獨的表。 歡迎各位看官們補充~吃瓜觀眾可點一波關注壓壓驚（還好我繞過了這些坑）恆生開發者社區-恆生電子面向所有開發者提供的服務分享、技術交流和互聯共通等一站式服務平台。