產(chǎn)品經(jīng)理對數(shù)據(jù)庫不必懂太多,這篇總結就夠了!
編輯導語:中臺和后臺產(chǎn)品經(jīng)理對于數(shù)據(jù)庫一定不陌生,本篇文章中,作者對數(shù)據(jù)庫進行了詳細地總結,幫助你更好的理解和應用數(shù)據(jù)庫,同時了解一些注意事項。
先把數(shù)據(jù)結構搞清楚,程序的其余部分自現(xiàn)?!?David Jones
對于中、后臺產(chǎn)品經(jīng)理而言,了解數(shù)據(jù)庫不是為了做斜杠青年,而是因為你就在面對數(shù)據(jù)庫。
本文目錄:
- 產(chǎn)品經(jīng)理對數(shù)據(jù)庫掌握兩點
- 理解數(shù)據(jù)庫
- 注意事項和規(guī)范
- 應用數(shù)據(jù)庫
- 常用查詢語句
一、產(chǎn)品經(jīng)理對數(shù)據(jù)庫掌握兩點
隨著業(yè)務橫向擴展,數(shù)據(jù)維度在擴大。隨著業(yè)務縱深發(fā)展,數(shù)據(jù)量在倍增。隨之而來的,是數(shù)據(jù)結構的不兼容、數(shù)據(jù)存儲不夠用,數(shù)據(jù)服務性能見拙,一切當初未考慮到的,都成了滋生障礙的伏筆。
產(chǎn)品不了解數(shù)據(jù)庫原理的話,常常會與技術方案之間信息割裂。近期表現(xiàn)為互相扯皮,長遠會引入“技術債”,并一度陷入插不上手、插不上嘴的懵逼狀態(tài)。
舉例兩個場景:
第一:當你發(fā)現(xiàn)數(shù)據(jù)異常,或者你要調(diào)研一個功能的時候,需要拉一批數(shù)據(jù)做驗證。
如果開發(fā)資源不夠,你就要一直等著。而多數(shù)大而老的ERP系統(tǒng)確實慘不忍睹,整個團隊很累很忙,這可能是你一段時間內(nèi)不得不面對的常態(tài)。——所以你要自力更生。
第二:當你寫需求的時候,在頁面截圖字段后畫個圈丟過去,看著沒毛病。但是一些值,根本不在頁面。
如果你能給出一點線索,就可以讓他效率高點。
所以,后端產(chǎn)品在工作中無法像C端產(chǎn)品那樣做甩手掌柜:事實上往往還要產(chǎn)品給開發(fā)一兩個建議方案,并告訴他要避免哪些坑,因為產(chǎn)品比開發(fā)多掌握了業(yè)務信息。
所以避不開數(shù)據(jù)庫、數(shù)據(jù)表、字段這些接近技術的問題,那么作為產(chǎn)品要了解數(shù)據(jù)庫到什么程度呢?
達到兩點即可:
- 理解數(shù)據(jù)庫作用原理,使你能更好與開發(fā)互相溝通,更好輸出方案;
- 會用簡單常用的SQL查詢?nèi)粘栴},實現(xiàn)基本的數(shù)據(jù)庫應用價值。
二、理解數(shù)據(jù)庫
1. 你在互聯(lián)網(wǎng)看到一切皆“下載”
下載的就是服務器上的數(shù)據(jù),廣義地說,凡是存儲數(shù)據(jù)的,都算是數(shù)據(jù)庫,包括瀏覽器的緩存。
前端界面看到的內(nèi)容,如果不是代碼寫死的,那么就是從數(shù)據(jù)庫調(diào)取的。這就是為什么你看到頁面會常常出現(xiàn)圖片滯后,因為圖片調(diào)用比較慢。
數(shù)據(jù)庫就好像是一個倉庫,開發(fā)用代碼實現(xiàn)對其中數(shù)據(jù)的取值,最終給到頁面呈現(xiàn)出來。
2. 數(shù)據(jù)庫管理三個階段
20世紀50年代中期以前,人工管理;20世紀50年代后到60年代中,文件系統(tǒng)階段,數(shù)據(jù)共享性差。20世紀60年代后期以來,出現(xiàn)了統(tǒng)一管理數(shù)據(jù)的專門軟件系統(tǒng)——DBMS。
3. 數(shù)據(jù)庫模型主要三種
層次式數(shù)據(jù)庫、網(wǎng)絡式數(shù)據(jù)庫和關系型數(shù)據(jù)庫,現(xiàn)今最常用的即關系型數(shù)據(jù)庫和非關系型數(shù)據(jù)庫。
4. 關系型數(shù)據(jù)庫
MYsql為典范,以二位報表的形式展示,因此MYSQL和PHP的組合是比較完美(報表多)。比MYsql強大的關系型數(shù)據(jù)庫還有ORACLE,比如1000W條數(shù)據(jù)以上級別的數(shù)據(jù),一般用的比較多的是ORACLE。
MYsql每張表只能有一個主鍵,但開發(fā)會創(chuàng)建多個字段的索引,目的是為了提高查詢速度,至少提升上百倍查詢速度。
5. 非關系型數(shù)據(jù)庫(NoSQL)
NoSQL是作為傳統(tǒng)關系型數(shù)據(jù)庫的一個有效補充,處理對存儲要求高,且并發(fā)處理較高的場合。
主要是數(shù)據(jù)庫Mongodb,數(shù)據(jù)是散漫的,以鍵值對的形式存儲,{?“key1”:”valude1”?,“key2”:” valude2 ”?,“key3”:” valude3”}。
6. 分布式賬本數(shù)據(jù)庫
區(qū)塊連的數(shù)據(jù)存儲方式,也有叫時間軸數(shù)據(jù)庫的,一種分布式的、集體維護的、按照時間順序將事件數(shù)據(jù)排列的“時間軸數(shù)據(jù)庫”,目前還不是主流的商業(yè)價值方案。
7. 圖片的存儲比較特別
一種是直接把圖片轉換成二進制文件存儲在數(shù)據(jù)庫中,適合存儲量少且重要的圖片信息;另一種是存儲圖片的路徑到數(shù)據(jù)庫,用的時候直接調(diào)用路徑給image等圖像控件即可,適合存儲量大但不是太重要的圖片。
第二種方法常用、簡單、實用。
三、注意事項和規(guī)范
1. 注意事項
- 建表的時候一般會增加冗余字段,比如 unique_code,用于存儲備用字段來標定唯一性;
- 建表的時候可以增加預留字段:當數(shù)據(jù)量大的時候很難再加新字段,所以預估到數(shù)據(jù)增張較快的,一定要預留幾個字段空位。便于日后數(shù)據(jù)表擴展;
- 當一個表無法再加字段的時候可以增加擴展表 ,后綴_ext ,與原表通過id關聯(lián)起來;
- 新增表字段:要考慮,到歷史數(shù)據(jù)初始化。比如歷史數(shù)據(jù)全部為空或刷為某一個值;
- 統(tǒng)一規(guī)范表名前綴,比如可以定義t_前綴標示類型, f_前綴表示從其他系統(tǒng)獲取的。
2. 命名規(guī)范
命名規(guī)范總的原則是可讀性強,容易維護,具體的規(guī)范如下:
- 庫名,表名,字段名,索引名統(tǒng)一使用小寫字母,數(shù)字,以下劃線分割;
- 庫名,表名,字段名不要超過30個字符長度;
- 庫名,表名,字段名不能單獨使用DB的關鍵字,像lock,time,date,return,user等;
- 數(shù)據(jù)庫的名稱為:業(yè)務名稱_[業(yè)務模塊]_db,eg:oms_db,oms_history_db;
- 非唯一索引按照“idx_字段名稱[_字段名稱]”,唯一索引按照“uk_字段名稱[_字段名稱]”進行命名;
- 業(yè)務系統(tǒng)使用數(shù)據(jù)庫賬號命名為:業(yè)務名稱_[r|w]。
3. 表名前綴
- 統(tǒng)計類數(shù)據(jù)表前綴:s
- 基礎數(shù)據(jù)表前綴:b
- 基礎類型維護數(shù)據(jù)表前綴:t
- 原始數(shù)據(jù)表前綴:in
- 訂單數(shù)據(jù)表前綴:o
- 同步隊列數(shù)據(jù)類型表前綴:iq
- 財務數(shù)據(jù)表前綴:f
4. 索引設計規(guī)范
- 單表索引個數(shù)不能超過30個;
- 關聯(lián)字段,業(yè)務外鍵,create_time 字段必須建索引;
- 在選擇性高的字段創(chuàng)建索引,注意組合索引的順序,利用索引的最左原則;
- 使用復合索引,而不是添加新的索引;
- 避免冗余索引。
idx_a_b_c(a,b,c)
idx_a(a)
idx_a_b(a,b)
四、應用數(shù)據(jù)庫
1. 安裝數(shù)據(jù)管理系統(tǒng)
以下介紹最常用的MYSQL,首先要在PC端安裝MYSQL數(shù)據(jù)庫服務器,然后通過公司的數(shù)據(jù)庫地址、密碼連接上數(shù)據(jù)庫(具體可以找開發(fā)協(xié)助完成)。
這樣你就可以進入到數(shù)據(jù)庫的各個表里看數(shù)據(jù),一個公司若有多個系統(tǒng),每個系統(tǒng)有至少一個屬于自己的數(shù)據(jù)庫,也有一個系統(tǒng)的數(shù)據(jù)分庫存放的。
2. 熟悉數(shù)據(jù)庫管理系統(tǒng)
數(shù)據(jù)庫的表可以創(chuàng)建很多個,每個表描述一種實體與屬性關系,每個屬性就是一個字段。同一個數(shù)據(jù)庫的表可以連表查詢,不同數(shù)據(jù)庫的表不能連表,因此在業(yè)務發(fā)展過程中會出現(xiàn)拆遷庫、拆表的行為。
1)數(shù)據(jù)組成
一個基本的數(shù)據(jù)由數(shù)據(jù)類型、字段(也叫變量或者參數(shù))、字段值組成:
CREATE TABLE `s_rule` (?`rule_id` int(11) NOT NULL AUTO_INCREMENT COMMENT ‘主鍵ID’,?`rule_name` varchar(255) NOT NULL DEFAULT ” COMMENT ‘規(guī)則名稱’,?`rule_type_id` int(11) unsigned NOT NULL DEFAULT ‘0’ COMMENT ‘規(guī)則類型id,對應t_oms_rule_type表的自增id’,`solution_desc` varchar(255) NOT NULL DEFAULT ” COMMENT ‘處理方式描述’。
這里的表名是s_rule,4個字段都不允許為空。
2)字段類型
這里的字段類型是對字段值的約束,約束的根本原因是代碼在執(zhí)行調(diào)用取值的時候,與數(shù)據(jù)庫一個約定,約定后就不會有不符合規(guī)制的數(shù)據(jù)進入,避免代碼識別障礙導致報錯,比如整形、字符串等。
3)主鍵
MYSQL每張表只能有一個主鍵,主鍵即為主關鍵字(primary key),可以由一個或多個字段組成,并且主關鍵字的列不能包含空值。
主鍵意義主要是用于其他表的外鍵關聯(lián),以及本記錄的修改與刪除。當兩個表需要關聯(lián)時,主關鍵字用來在一個表中引用來自于另一個表中的特定記錄,一般用該表id做主鍵。
4) 索引
索引是由開發(fā)在設計表之后,再具體創(chuàng)建的,對數(shù)據(jù)庫表中一或多個字段值進行排序的一種結構,使用索引可快速訪問數(shù)據(jù)庫表中的特定信息。
數(shù)據(jù)庫索引好比是一本書前面的目錄,能加快數(shù)據(jù)庫的查詢速度。例如:這樣一個查詢:select * from table1 where id=44。
如果沒有索引,必須遍歷整個表,直到ID等于44的這一行被找到為止;有了索引之后(必須是在ID這一列上建立的索引),直接在索引里面找44(也就是在ID這一列找),就可以得知這一行的位置,也就是找到了這一行。
可見,索引是用來定位的。索引分為聚簇索引和非聚簇索引兩種,了解即可。主鍵唯一,但是表的索引可以有多個。
增加索引也有許多不利的方面 :
- 創(chuàng)建索引和維護索引要耗費時間,這種時間隨著數(shù)據(jù)量的增加而增加;
- 索引需要占物理空間,除了數(shù)據(jù)表占數(shù)據(jù)空間之外,每一個索引還要占一定的物理空間,如果要建立聚簇索引,那么需要的空間就會更大;
- 當對表中的數(shù)據(jù)進行增加、刪除和修改的時候,索引也要動態(tài)的維護,這樣就降低了數(shù)據(jù)的維護速度。
五、常用查詢語句
1. 數(shù)據(jù)查詢介紹
操作數(shù)據(jù)庫的話,全世界的程序員都是統(tǒng)一的,都是用SQL語句來操作數(shù)據(jù)庫。
產(chǎn)品經(jīng)理一般不去建表、改表,所以create table <表名> 、alter table <表名>、drop table <表名>知道就可以。
產(chǎn)品更多是查詢、統(tǒng)計,或者寫出更新/插入/刪除語句,讓開發(fā)執(zhí)行。查詢語句中你可以使用一個或者多個表,表之間使用逗號(,)分割,并使用WHERE語句來設定查詢條件。
SELECT 命令可以讀取一條或者多條記錄:
- 可以使用星號*來代替全部字段,SELECT語句會返回表的所有字段數(shù)據(jù);
- 可以使用 WHERE 語句來包含任何條件;
- 可以使用 LIMIT 屬性來設定返回的記錄數(shù);
- 可以通過OFFSET指定SELECT語句開始查詢的數(shù)據(jù)偏移量等等。
2. SQL語句技巧簡介
1)where和having區(qū)別:
- where在分組前過濾,having在分組后過濾;
- having 字段必須是查詢出來的,where 字段必須是數(shù)據(jù)表存在的;
- where 不可以使用字段的別名,having 可以。因為執(zhí)行WHERE代碼時,可能尚未確定列值;
- where 不可以使用合計函數(shù)。一般需用聚合函數(shù)才會用 having。
2)and優(yōu)先級高于or,一般這種混合的句子建議用()使關系清晰,比如A>0 OR B<0 and c=0,相當于A>0 OR( B<0 and c=0)。
3)點擊‘美化SQL’按鈕,可以將語句斷層使層次清晰,比如where name in(‘A’,’B’,’C),美化后:where goods_sn in(‘A’,’B’,’C)。
4)導出的表頭換成漢字注釋的方式:SELECT a.ds_sn as編碼 ,a.pdt_name as ?名稱 ?FROM p_pro。
5)?is和=有時是不同的,比如寫作is null ,而不寫=null。
6)MySQL中,null是未知的,且占用空間的??罩?”)是不占用空間的,注意空值的”之間是沒有空格。
在進行count()統(tǒng)計某列的記錄數(shù)的時候,如果采用的 NULL 值,會被系統(tǒng)自動忽略掉,但是空值是會進行統(tǒng)計到其中的。判斷null使用is null或者is not null,但判斷空字符使用? =”或者? <>”來進行處理。
7)?配合函數(shù)
- count():統(tǒng)計記錄數(shù)
- avg():計算字段值的平均值
- sum():計算字段值的總和
- max():查詢字段的最大值
- min():查詢字段的最大值
比如:select count(id) from p_product。
8)排序:order by 字段 desc/ASC,select * from finance_order order by update_time desc limit 3。
9)?包含某個字符:select * from table where 列名 like ‘a(chǎn)%’(利用模糊查詢)。
10)? 查詢表p_product中的第10、11、12、13行數(shù)據(jù):select * from product limit 4 offset 9;或?select * from product limit 9,4。
11)?去重搜索:SELECT distinct(goods) FROM。
12) GROUP BY 語句進行組合:SELECT Customer,SUM(OrderPrice) FROM Orders GROUP BY Custome。
13)查詢?nèi)齻€字段維度 重復的數(shù)據(jù)
- select account,platform_sku,goods_sn, count(1) from t_oms_sku_map
- where id <1000000
- group by account,platform_sku,goods_sn
- having( count(1) > 1)
- limit 100
14)字段拼接
select concat(‘123′,’456’),mysql中的concat則可以拼接多個字符串。
將一個訂單對應的多個產(chǎn)品輸入在一起,select ?order_sn ,group concat (goods_sn)from 訂單商品表。
15) in 括號內(nèi)為或的關系
select name from product where ? goods in (‘103702505′,’103702805’) and (shelf_time >? ‘2014-09-15 16:53:21’ or title like ‘_tylish%’)。
16)連表查詢用join
Inner Join最常見,叫做內(nèi)聯(lián)接,可以縮寫成Join,找的是兩張表共同擁有的字段。Left Join叫做左聯(lián)接,以左表(join符號前的那張表)為主,返回所有的行。如果右表有共同字段,則一并返回,如果沒有,則為空。
A Full Join B = A Left Join B + A Right Join B – A Inner Join B
還有其他連表方式既然用網(wǎng)絡的圖片:
17)數(shù)據(jù)備份
選中數(shù)據(jù),右鍵點擊復制為insert/update,可以直接將篩選的字段備份為更新或插入語句,一旦需要還原的時候可以直接執(zhí)行這幾個語句。
18)多個獨立的查詢語句之間可以用;隔開,同時執(zhí)行,會分別輸出。
#專欄作家#
唧唧歪歪PM,公眾號:唧唧歪歪PM(ID:jjyypm),人人都是產(chǎn)品經(jīng)理專欄作家,2019年年度作者?!逗蠖水a(chǎn)品經(jīng)理寶典》作者,藥學碩士轉行互聯(lián)網(wǎng)產(chǎn)品多年;熟悉跨境電商業(yè)務,醫(yī)藥領域;擅長大型后臺體系,社交APP。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉載
題圖來自Unsplash,基于CC0協(xié)議
專欄作家
唧唧歪歪PM,公眾號:唧唧歪歪PM(ID:jjyypm),人人都是產(chǎn)品經(jīng)理專欄作家,2019年年度作者。《后端產(chǎn)品經(jīng)理寶典》作者,藥學碩士轉行互聯(lián)網(wǎng)產(chǎn)品多年;熟悉跨境電商業(yè)務,醫(yī)藥領域;擅長大型后臺體系,社交APP。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉載
題圖來自Unsplash,基于CC0協(xié)議。
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。
后胎昨的我頭大。。
這些對于產(chǎn)品來說根本沒有什么卵用,真正有水的是那些技術轉型過去的產(chǎn)品經(jīng)理,其他通過UI轉過去的基本不懂技術,在技術面前基本不敢插話!總之知識面廣對于一個產(chǎn)品來說非常重要!產(chǎn)品+技術+設計=NB
開發(fā)出身做產(chǎn)品,后面UI缺人,兼職搞了一下UI,小企業(yè)的產(chǎn)品才牛逼
小企業(yè)的產(chǎn)品最后基本都被逼到全棧了。