用日誌記錄「開源軟體」的誕生
點亮星標，感謝支援，與開發者交流 kzca2000
碼雲：github：
赤龍erp官網：
我在每乙個表幾乎無一例外的都增加了兩個預設的字段，即id和code。這兩個字段看似都是可標識資料的唯一性字段，但為什麼要設計兩個呢？它們當然各有用途。
（1）id是乙個表的主鍵，一般都是自增的，主要用於排序、定位、查詢，由於它是數字所以更清晰、速度更快。
（2）code是唯一鍵，型別多是字元。可用uuid或雪花演算法等生成。當然在有具體業務場景的情況下，可以由使用者輸入或按邏輯生成。除了可以具備強語義外，還優先用於外來鍵的關聯。
這裡做個特殊說明：為什麼要用code做外來鍵，id也可以做外來鍵啊。外來鍵要具備兩個最大的特點：唯一，不可變。id由於多是自增或由資料庫的特質生成，所以不能保證在資料遷移時絕對不變。所以使用code更安全可靠一些。這個欄位名為：org_code，表示組織機構。那什麼是組織機構呢？簡單說就是獨立的公司或主體。作用主要是用於資料隔離，由於沒有必要為不同公司建立不同的資料表，所以用乙個欄位將不同公司的資料隔離開。有點像財務的賬套的概念。
在每個表都會增加四個字段，用來記錄誰在什麼時間做了資料操作。分別為：
（1）created_date（建立時間）
（2）last_updated_date（最後修改時間）
（3）created_by（建立人）
（4）last_updated_by（最後修改人）
建立人和建立時間，在資料新增的時候設定；最後修改人和最後修改時間，在資料更新的時候設定資訊化系統都需要資料許可權的控制，即什麼人可以操作哪些資料。一般企業級資訊化，資料許可權的邏輯都是在組織架構的層面進行控制的。一般包括：自己操作自己的資料、不同級別部門內的資料可共享、整個公司的資料共享。
為了解決上述的資料許可權控制的需要，所以增加乙個欄位department_code(部門編碼)。這個欄位只會記錄建立當前資料的人所屬的部門，即這條資料的所屬部門。**層面再結合資料許可權，即可實現資料許可權的管控。
在需要記錄資料版本的表中增加version（版本號），常見的業務場景就是「變更功能」。下面舉個例子，比如：採購訂單變更。當我們建立了乙個採購訂單，並且審批通過後，這個資料本質是不能修改的，但出現需要修改的時候，我們就需要用上採購訂單變更功能。當訂單變更時，需要做的就是版本號+1，並且在日誌表生成歷史資料。
自定義欄位的作用是讓使用者可以根據自己的業務需要增加乙個表的字段並儲存資料。做法是需要在乙個表中增加attribute欄位，多數情況下會預留多個attribute欄位，欄位名attribute1、attribute2、attribute3以此類推。然後再通過可配置的功能來設定attribute欄位和字段中文名的對應關係即可。
你不知道的那些console
前一陣在查詢問題的時候，偶然間發現了console的乙個用法，彷彿開啟了我新世界的大門，原來console還有這麼多的用法，這讓一直以來只用console.log 的我情何以堪啊，所以在這裡記錄一下我認為有意思和比較實用的幾種用法。console.log 文字資訊 console.info 提示資訊...
那些你不知道的meta標籤
作為一名切圖仔，對meta一直都是用於seo優化 設定視口標籤，但是最近一段時間檢視 京東 蘇寧等 的前端 卻發現meta標籤的使用多種多樣，這才知道自己一直小覷了meta標籤。在陸續看了其他幾家大型 的前端 和翻閱了相關資料寫下了這篇文章，如果文章中有什麼錯誤，麻煩指出，立即更正。http equ...
你不知道的那些「XX即服務」
雲計算引發了一系列xx即服務的新模式，從早期的軟體即服務 saas 到現在流行的網路即服務 naas 各種 xx即服務 的術語也讓很多it工作者覺得一頭霧水，本期的資訊化內參，帶你全面了解各種各樣的xx即服務。在雲計算之前，上乙個資料倉儲和商業智慧型專案通常意味著花費數月獲取硬體和軟體，實現自定製設...