從項(xiàng)目啟動(dòng)之時(shí)，數(shù)據(jù)庫設(shè)計(jì)工作就已經(jīng)開始蔑水，貫穿于項(xiàng)目前期階段的需求調(diào)研、分析扬蕊、確認(rèn)搀别、業(yè)務(wù)梳理過程，只不過這時(shí)的設(shè)計(jì)大都停留在腦海中尾抑，正式的設(shè)計(jì)過程起始于最終的需求確認(rèn)完成歇父、業(yè)務(wù)梳理清晰之后。
就目前來看再愈，最好的關(guān)系型數(shù)據(jù)庫設(shè)計(jì)工具還是PowerDesigner（以后簡稱PD）庶骄，我們要求正式數(shù)據(jù)庫設(shè)計(jì)過程中必須使用此工具，先出CDM（Concept Data Model践磅，概念數(shù)據(jù)模型）单刁，再根據(jù)實(shí)際的數(shù)據(jù)庫類型由CDM導(dǎo)出PDM（Physical Data Model，物理數(shù)據(jù)模型）府适，最后由PDM將設(shè)計(jì)成果直接導(dǎo)入到數(shù)據(jù)庫中羔飞。同時(shí)導(dǎo)出相應(yīng)的數(shù)據(jù)庫文檔，以供項(xiàng)目組開發(fā)人員查閱檐春。
CDM設(shè)計(jì)過程中只做最簡單必要的設(shè)計(jì)逻淌，約束、關(guān)系疟暖、主鍵卡儒、外鍵、命名規(guī)則等在轉(zhuǎn)換成PDM過程中PD可自行處理的部分均交由工具自行處理俐巴。就是說數(shù)據(jù)庫設(shè)計(jì)者只負(fù)責(zé)工具無法處理的少許部分骨望，工具可完成的部分則用工具統(tǒng)一處理，這樣設(shè)計(jì)工作會(huì)更高效省時(shí)欣舵，最終的設(shè)計(jì)成果也會(huì)更規(guī)范合理擎鸠。
初版數(shù)據(jù)庫設(shè)計(jì)完成之后進(jìn)入項(xiàng)目開發(fā)階段，如果前期的需求調(diào)研分析缘圈、業(yè)務(wù)梳理沒問題劣光，后期數(shù)據(jù)庫結(jié)構(gòu)發(fā)生大規(guī)模改動(dòng)的情況不應(yīng)該頻繁出現(xiàn)的。但需求總是在變糟把，意外才是唯一的法則绢涡，即便設(shè)計(jì)者在前期調(diào)研、了解遣疯、分析雄可、設(shè)計(jì)的過程中再過謹(jǐn)慎，怕只能減少這種情況出現(xiàn)的風(fēng)險(xiǎn)，卻不能完全避免滞项。還有隨著開發(fā)的深入狭归，數(shù)據(jù)庫結(jié)構(gòu)發(fā)生局部變動(dòng)夭坪，比如增刪改些表字段等也是再正常不過的了文判。針對(duì)這些，都應(yīng)該有相應(yīng)的對(duì)策室梅，才能以不變應(yīng)萬變戏仓。
第一版的數(shù)據(jù)庫設(shè)計(jì)完成，由PDM生成相應(yīng)的SQL腳本在數(shù)據(jù)庫中執(zhí)行之后亡鼠，隨開發(fā)深入而再進(jìn)行的數(shù)據(jù)庫改動(dòng)分兩種情況：一種是大改赏殃，比如原有的業(yè)務(wù)有變動(dòng)，或因在設(shè)計(jì)時(shí)考慮不周间涵、對(duì)需求了解不清導(dǎo)致設(shè)計(jì)出錯(cuò)仁热，表及引用關(guān)系都要發(fā)生重大變化，剛也說了這種情況不應(yīng)該出現(xiàn)勾哩；另一種是小改抗蠢，比如有新增業(yè)務(wù)的情況要新建些表，有拿掉部分業(yè)務(wù)的情況可能會(huì)刪除些表思劳，還有更常出現(xiàn)的是增刪改部分表的部分字段迅矛。
對(duì)于以上兩種，有增加表或大規(guī)模業(yè)務(wù)變動(dòng)的情況潜叛，建議是在PD中修改PDM秽褒，然后重新生成SQL腳本在數(shù)據(jù)庫中執(zhí)行，當(dāng)然只生成新增表或發(fā)生業(yè)務(wù)變動(dòng)部分的即可威兜，而對(duì)于簡單的增刪改些字段或業(yè)務(wù)變動(dòng)不大的情況销斟，建議直接在數(shù)據(jù)庫中對(duì)表進(jìn)行修改。然后通過PD菜單中的Database——Update Model from Database……連接數(shù)據(jù)庫逆向更新PDM椒舵，使PDM和最新的數(shù)據(jù)庫結(jié)構(gòu)保持一致票堵，而后再生成最新的數(shù)據(jù)庫文檔。但要注意的是逮栅，使用此功能逆向更新PDM悴势，只會(huì)更新修改或新增的表字段，而不更新刪除的字段措伐。就是說特纤，如果在數(shù)據(jù)庫中對(duì)一個(gè)表的字段進(jìn)行了修改，或者新增了一些字段侥加，PD會(huì)同步在PDM中的相應(yīng)表中做出相應(yīng)的修改或新增捧存，但如果在數(shù)據(jù)庫中刪除了表中的某個(gè)字段，PD是不會(huì)刪除PDM中相應(yīng)表的相應(yīng)字段的。為什么這般處理昔穴，自己也覺得很奇怪镰官。
后期的數(shù)據(jù)庫改動(dòng)，一般發(fā)生在程序開發(fā)啟動(dòng)后吗货，如果主程序可自動(dòng)生成泳唠，第二種小改的情況還是比較容易處理的，重新生成下主程序宙搬，而手寫的部分（非自動(dòng)生成部分）一般不會(huì)受到太大影響笨腥。但如果是第一種情況，業(yè)務(wù)發(fā)生了變動(dòng)勇垛，那可能意味著手寫的程序（非自動(dòng)生成部分）要重寫脖母。之前的文章中也有提及，一定要注意前期的需求調(diào)研了解分析系統(tǒng)設(shè)計(jì)闲孤，后期的問題幾乎都是由前期的不慎造成谆级，有經(jīng)驗(yàn)的項(xiàng)目經(jīng)理可以在前期預(yù)料到后面可能的問題而提前采取相應(yīng)的預(yù)防措施。防之于未有讼积，治之于未亂肥照。項(xiàng)目想要做的出色，有太多不可測因素币砂，但如果手底下的項(xiàng)目都很穩(wěn)當(dāng)建峭，其能力必是值得肯定的。
這里還要提一點(diǎn)决摧，后期數(shù)據(jù)庫表小范圍的修改一般是由開發(fā)人員發(fā)現(xiàn)亿蒸，比如在開發(fā)過程中發(fā)現(xiàn)少了一些字段，或局部業(yè)務(wù)有些問題等等掌桩，應(yīng)該禁止開發(fā)人員擅自直接更改數(shù)據(jù)庫边锁，所有更改無論大小必須經(jīng)過數(shù)據(jù)庫主設(shè)計(jì)師的審核同意，以避免可能影響到全局的更改出現(xiàn)波岛。
數(shù)據(jù)庫的設(shè)計(jì)工作雖然集中在項(xiàng)目的業(yè)務(wù)梳理清晰之后茅坛、正式開發(fā)之前，但相關(guān)細(xì)枝末節(jié)的工作卻不止于此则拷，很可能會(huì)貫穿于整個(gè)項(xiàng)目的起始流程贡蓖。
有人說數(shù)據(jù)庫難以設(shè)計(jì)，其實(shí)難的并不是數(shù)據(jù)庫的設(shè)計(jì)煌茬，而是業(yè)務(wù)流程的梳理斥铺。再復(fù)雜的業(yè)務(wù)，只要理得清坛善，表現(xiàn)在數(shù)據(jù)庫中晾蜘，無外乎是表與表間的三種關(guān)系：一對(duì)一（one-to-one）邻眷、一對(duì)多（one-to-many）以及多對(duì)多（many-to-many）。更進(jìn)一步的剔交，many-to-many實(shí)際上就是兩個(gè)one-to-many肆饶。
在Java中萬事萬物皆對(duì)象，在關(guān)系型數(shù)據(jù)庫中萬事萬物皆是二維表岖常，而事物之間的聯(lián)系系就是表與表間的這三種關(guān)系驯镊。
后面還會(huì)多次提及，我們的設(shè)計(jì)原則是盡可能讓粒度小腥椒、容忍度高阿宅，比如在“設(shè)計(jì)規(guī)范”——“字段設(shè)置”——“通用字段處理”中有關(guān)于日期時(shí)間類型設(shè)置的說明候衍，要求日期時(shí)間類型的字段笼蛛，盡可能用datetime類型，精確到時(shí)分秒蛉鹿，而不要用date類型滨砍。表現(xiàn)在這里，處理業(yè)務(wù)關(guān)系時(shí)妖异，對(duì)于核心業(yè)務(wù)部分尚不能明確表與表關(guān)系的惋戏，能一對(duì)多就不要一對(duì)一，能多對(duì)多就不要一對(duì)多他膳。這樣開發(fā)的復(fù)雜度會(huì)增加响逢，卻消除了后面可能的修改擴(kuò)展的隱患。對(duì)于非核心業(yè)務(wù)也不能明確關(guān)系的棕孙，可根據(jù)實(shí)際情況舔亭，綜合考量開發(fā)實(shí)現(xiàn)的煩瑣程度及未來的可變性再做決定。
PD細(xì)化了這三種關(guān)系的表述蟀俊，表現(xiàn)在CDM關(guān)系中Cardinalities選項(xiàng)卡的Cardinality選項(xiàng)中钦铺、表現(xiàn)在PDM引用中Integrity選項(xiàng)卡的Cardinality選項(xiàng)中。Cardinality肢预，基數(shù)矛洞，在CDM的選項(xiàng)中表示另一方對(duì)于當(dāng)前方的每個(gè)實(shí)例，可能擁有的實(shí)例的最少和最多數(shù)烫映；在PDM的選項(xiàng)中表示父表中的每個(gè)實(shí)例沼本，子表中可能擁有的實(shí)例的最少和最多數(shù)。
比如“病人”與“會(huì)診單”兩個(gè)實(shí)體之間的聯(lián)系是one-to-many聯(lián)系锭沟，換個(gè)方向說“會(huì)診單”和“病人”之間的聯(lián)系是many-to-one聯(lián)系抽兆。而且一個(gè)會(huì)診單必須屬于一個(gè)病人，并且只能屬于一個(gè)病人冈钦，不能屬于零個(gè)病人郊丛，所以從“會(huì)診單”實(shí)體至“病人”實(shí)體的基數(shù)為“1,1”李请；從聯(lián)系的另一方向考慮，一個(gè)病人可以擁有多個(gè)會(huì)診單厉熟，也可以沒有任何會(huì)診單导盅，即零個(gè)會(huì)診單，所以該方向聯(lián)系的基數(shù)就為“0,n”揍瑟。CDM中的表示如下圖所示：
在構(gòu)建CDM白翻、選擇兩個(gè)實(shí)體之間的關(guān)系時(shí)，這部分會(huì)自動(dòng)賦值的绢片。
類似的滤馍，一個(gè)品牌必需且只能屬于一個(gè)企業(yè)，一個(gè)企業(yè)卻可以有一個(gè)或多個(gè)品牌底循，又或者一個(gè)也沒有巢株。在PDM的選項(xiàng)中表示父表為企業(yè)、子表為品牌熙涤，父表（企業(yè)）中的每個(gè)實(shí)例阁苞，子表（品牌）中可能擁有的實(shí)例的最少和最多數(shù)。如下圖所示：
PD的細(xì)化在于祠挫，one-to-one關(guān)系中到底是must have one and only one還是may have at most one那槽，one-to-many關(guān)系中到底是must have one or more還是may have one or more。many-to-many關(guān)系需要借助中間表實(shí)現(xiàn)等舔，分解成兩個(gè)one-to-many組合骚灸，類似的，也可被細(xì)分成嚴(yán)格的多對(duì)多還是模糊的多對(duì)多慌植∩跎可以拿用戶和角色的例子說明，嚴(yán)格的多對(duì)多是一個(gè)用戶至少有一個(gè)角色涤浇、一個(gè)角色至少被一個(gè)用戶擁有鳖藕，模糊的多對(duì)多是一個(gè)用戶可以沒有任何角色、一個(gè)角色可以不被任何用戶擁有只锭。
個(gè)人認(rèn)為對(duì)one-to-many和many-to-many兩種關(guān)系進(jìn)行細(xì)化的意義不大著恩，因?yàn)閷?duì)于one-to-many、many-to-one蜻展，無論是否嚴(yán)格喉誊，都要在many方加入引用one方主鍵的外鍵；而對(duì)于many-to-many纵顾，無論是否嚴(yán)格伍茄，中間表都是必須的。所以對(duì)于這兩種關(guān)系施逾，無論是否為嚴(yán)格的敷矫，設(shè)計(jì)方案是確定的例获。
但對(duì)于one-to-one，嚴(yán)格的和非嚴(yán)格關(guān)系之間設(shè)計(jì)上是有區(qū)別的曹仗。比如訂單和取消原因榨汤，一個(gè)訂單可以有一個(gè)或零個(gè)取消原因（may have at most one），本來如果是嚴(yán)格的一對(duì)一關(guān)系怎茫，取消原因是可以整合到訂單表中的收壕，而無需單建表存儲(chǔ)。再比如班級(jí)與班長轨蛤，一個(gè)班級(jí)只有一個(gè)正班長蜜宪，一個(gè)班長只在一個(gè)班中任職，兩邊都是must have one and only one祥山，那班長表完全可以省略圃验，而直接在班級(jí)表中加入相應(yīng)描述班長信息的字段即可，比如班長名稱枪蘑、性別等等损谦，又或者直接有個(gè)班長的外鍵字段指向?qū)W生表岖免。
拿到項(xiàng)目后岳颇，完成早期的需求調(diào)研，在分析設(shè)計(jì)的過程中颅湘，先考慮的是要實(shí)現(xiàn)所需功能话侧、需要的實(shí)體有哪些。比如要實(shí)現(xiàn)登錄功能闯参，那必需要有用戶實(shí)體瞻鹏。繼續(xù)擴(kuò)展思路，登錄往往伴隨著角色劃分鹿寨，為此要有角色新博、權(quán)限相關(guān)的實(shí)體。為了記錄登錄請(qǐng)求脚草，又要有登錄日志實(shí)體赫悄。這些實(shí)體表現(xiàn)在數(shù)據(jù)庫即為相應(yīng)的表，實(shí)體確定馏慨，同步考慮實(shí)體與實(shí)體間的關(guān)系埂淮。一個(gè)用戶可以有多個(gè)角色，一個(gè)角色可以被多個(gè)用戶擁有写隶，所以用戶和角色是多對(duì)多關(guān)系倔撞，多對(duì)多關(guān)系意味著出現(xiàn)中間表。一個(gè)用戶可以有多條登錄日志慕趴，一條登錄日志有且只能對(duì)應(yīng)一個(gè)用戶痪蝇，所以用戶和登錄日志是一對(duì)多的關(guān)系鄙陡，登錄日志表中要有外鍵引用用戶表。這就是數(shù)據(jù)庫設(shè)計(jì)的過程躏啰。
數(shù)據(jù)庫的設(shè)計(jì)往往和前端界面的設(shè)計(jì)并行柔吼，前者稍晚于后者，兩者的進(jìn)行伴隨在業(yè)務(wù)梳理的過程中丙唧、前期需求確認(rèn)之后愈魏，為確保對(duì)需求理解的準(zhǔn)確性、設(shè)計(jì)的準(zhǔn)確性想际，此過程中應(yīng)該繼續(xù)和需求提出者保持溝通培漏。如果在設(shè)計(jì)數(shù)據(jù)庫時(shí)不考慮前端界面設(shè)計(jì)、或者是在設(shè)計(jì)界面時(shí)不考慮數(shù)據(jù)庫設(shè)計(jì)胡本，且不說兩邊對(duì)業(yè)務(wù)需求的理解可能有偏差牌柄，即便完全沒有，最終怕也不能完好無誤的進(jìn)行融合侧甫，這也是為什么覺得項(xiàng)目經(jīng)理珊佣、產(chǎn)品經(jīng)理、技術(shù)經(jīng)理的角色一人扮演要比三人分飾更好的原因披粟。成熟的社會(huì)體制下咒锻，人與人間的分工應(yīng)該更加明確，這無可厚非守屉，問題就出在很多公司分工提前明確了惑艇，協(xié)作體制卻不完善。如此這般拇泛，做一件事情參與的人越多滨巴，不但不會(huì)節(jié)省工時(shí)，反而導(dǎo)致的問題越多俺叭，大大降低了工作效率恭取。
負(fù)責(zé)數(shù)據(jù)庫設(shè)計(jì)工作的人應(yīng)該是最懂項(xiàng)目、最懂業(yè)務(wù)需求熄守、最有設(shè)計(jì)經(jīng)驗(yàn)的人蜈垮，此人必須跟蹤整個(gè)項(xiàng)目的設(shè)計(jì)開發(fā)過程，產(chǎn)品界面的設(shè)計(jì)柠横、程序的開發(fā)都要和其溝通確認(rèn)方可窃款。項(xiàng)目設(shè)計(jì)開發(fā)實(shí)施過程中，很多決定牍氛，不是參與決定的人越多越好晨继，而是由一個(gè)最懂項(xiàng)目的人決定最好。有時(shí)為了某個(gè)決定組織集體討論搬俊，最終的決定往往來自于主導(dǎo)討論者紊扬，而非是最懂項(xiàng)目者蜒茄。做項(xiàng)目和帶兵打仗一樣，最怕飯桶主導(dǎo)局勢餐屎。而做為項(xiàng)目主負(fù)責(zé)人檀葛，你可以不是最懂項(xiàng)目的，但一定要清楚的是這個(gè)項(xiàng)目安排給誰去懂最合適腹缩，他有沒有這個(gè)能力屿聋、是否能聽從安排。一旦讓他去懂藏鹊，在項(xiàng)目推進(jìn)過程中觀察他是否能勝任润讥、各子環(huán)節(jié)最懂的那個(gè)人又是誰。明白誰最懂盘寡、誰肯聽眾安排楚殿，則把相應(yīng)部分的決定權(quán)交到相應(yīng)最懂、最聽從安排的人手中竿痰。而后除非出現(xiàn)特殊情況脆粥，自己不要去干涉、也不要讓其他人去干涉影涉。
原則上講变隔，百張表內(nèi)的數(shù)據(jù)庫最好由一人來設(shè)計(jì)。一百張表常潮，即使每張有一百個(gè)字段弟胀，總共也不過一萬個(gè)，如果用工具生成喊式，三五天內(nèi)足夠。當(dāng)然數(shù)據(jù)庫設(shè)計(jì)工作的難易并非是由表個(gè)數(shù)萧朝、字段個(gè)數(shù)決定的岔留，而更多在于業(yè)務(wù)的復(fù)雜程度。表個(gè)數(shù)检柬、字段個(gè)數(shù)在一定程度上可以反應(yīng)出業(yè)務(wù)的復(fù)雜程度献联，但卻非決定性因素。這里講百張表內(nèi)的設(shè)計(jì)工作量并不大何址，是說業(yè)務(wù)理清后將設(shè)計(jì)具體化成CDM里逆、PDM的體力工作。要求由一人來設(shè)計(jì)是為了確保最終數(shù)據(jù)庫的統(tǒng)一性用爪、完整性原押、協(xié)調(diào)性，如果不能保證統(tǒng)一偎血，最終項(xiàng)目的穩(wěn)定性絕對(duì)得不到保障诸衔。不僅數(shù)據(jù)庫的設(shè)計(jì)如此盯漂，架構(gòu)、程序笨农、前端就缆、樣式、腳本谒亦、UI都一樣竭宰。在項(xiàng)目設(shè)計(jì)階段，通常情況下份招，局部模塊設(shè)計(jì)的優(yōu)良并不會(huì)提升整個(gè)項(xiàng)目的質(zhì)量羞延，然而局部模塊設(shè)計(jì)出現(xiàn)的問題最終卻可能撼動(dòng)整個(gè)項(xiàng)目的穩(wěn)定。千里之堤毀于蟻穴脾还，務(wù)必要確保設(shè)計(jì)工作的謹(jǐn)慎協(xié)調(diào)統(tǒng)一伴箩。再說大部分企業(yè)內(nèi)部應(yīng)用系統(tǒng)，項(xiàng)目規(guī)模有限鄙漏，一個(gè)人主設(shè)計(jì)足夠嗤谚。
特殊情況下，如果項(xiàng)目大到一定程度怔蚌，所有數(shù)據(jù)庫設(shè)計(jì)工作交到一人手上著實(shí)過量巩步，不得不安排多人參與其中，那主設(shè)計(jì)師也必須只有一位桦踊，且所有參與人員都要嚴(yán)格遵守相應(yīng)的數(shù)據(jù)庫設(shè)計(jì)規(guī)范椅野。要利用PD的版本控制功能協(xié)調(diào)統(tǒng)一，最終由主設(shè)計(jì)師匯總校驗(yàn)所有人的設(shè)計(jì)籍胯，最終的數(shù)據(jù)庫設(shè)計(jì)應(yīng)該看起來像一個(gè)人的杰作竟闪，這也是程序、腳本杖狼、樣式炼蛤、UI設(shè)計(jì)開發(fā)所追求的目標(biāo)。
主設(shè)計(jì)師匯總校驗(yàn)之后蝶涩，還應(yīng)再組織會(huì)議對(duì)設(shè)計(jì)成果校驗(yàn)理朋，包括所有參與設(shè)計(jì)的人員、程序開發(fā)人員等绿聘，一起討論嗽上。查找可能出現(xiàn)的不合理的地方，比如有部分可能和需求業(yè)務(wù)不合熄攘、可能會(huì)影響到開發(fā)實(shí)現(xiàn)等等兽愤。數(shù)據(jù)庫的校驗(yàn)審核工作，參與人員盡可能多點(diǎn)，鼓勵(lì)提問烹看，有助于查缺補(bǔ)漏国拇，發(fā)現(xiàn)問題。
有公司規(guī)定所有項(xiàng)目的數(shù)據(jù)庫設(shè)計(jì)惯殊，DBA必須參與酱吝，但數(shù)據(jù)庫設(shè)計(jì)工作重在對(duì)業(yè)務(wù)的把控、了解土思，其次才是對(duì)數(shù)據(jù)庫本身的了解务热，這兩項(xiàng)缺一不可，且前者更為重要己儒。DBA的專業(yè)技能或許會(huì)更好一點(diǎn)崎岂，但是對(duì)業(yè)務(wù)的了解呢？還有公司的運(yùn)維團(tuán)隊(duì)中闪湾，DBA會(huì)脫離項(xiàng)目實(shí)際冲甘，設(shè)置一些不必要的數(shù)據(jù)庫規(guī)范，強(qiáng)加給開發(fā)團(tuán)隊(duì)途样。
在做項(xiàng)目時(shí)江醇，一方面非常討厭外部強(qiáng)加的規(guī)范，另一方面又不停的給自己何暇、給團(tuán)隊(duì)設(shè)定規(guī)范陶夜。討厭外部強(qiáng)加的規(guī)范是因?yàn)檫@些規(guī)范大都是些PMO指定的人憑空設(shè)想出來、脫離項(xiàng)目實(shí)際的裆站，這些規(guī)范只會(huì)給項(xiàng)目帶來更多的麻煩条辟。而給自己和團(tuán)隊(duì)設(shè)定規(guī)范，則是為了約束設(shè)計(jì)和開發(fā)行為宏胯，確保項(xiàng)目最終實(shí)現(xiàn)的合理統(tǒng)一協(xié)調(diào)羽嫡，這在后面的“命名規(guī)范”——“引言”中還有進(jìn)一步的說明。
大的項(xiàng)目胳嘲、大的團(tuán)隊(duì)可能會(huì)有多個(gè)專業(yè)DBA負(fù)責(zé)數(shù)據(jù)庫維護(hù)工作厂僧，但就自己接觸，即便公司了牛、團(tuán)隊(duì)本身有DBA，絕大部分規(guī)模的項(xiàng)目中數(shù)據(jù)庫維護(hù)工作還是多由程序開發(fā)人員兼顧辰妙。再者鹰祸，真正優(yōu)秀的DBA少之又少，有時(shí)不夠?qū)I(yè)的DBA過多介入反而會(huì)阻礙項(xiàng)目的正常開發(fā)密浑。
DBA出現(xiàn)的時(shí)機(jī)應(yīng)該是在開發(fā)人員無法解決數(shù)據(jù)庫出現(xiàn)的問題時(shí)蛙婴，比如當(dāng)數(shù)據(jù)量大到一定程度，項(xiàng)目運(yùn)行緩慢尔破，僅憑程序優(yōu)化已遇到瓶頸街图，這時(shí)可以向公司申請(qǐng)DBA介入浇衬，優(yōu)化數(shù)據(jù)庫設(shè)計(jì)、SQL語句等餐济。再比如遇到數(shù)據(jù)備份問題耘擂、出現(xiàn)數(shù)據(jù)丟失問題等，也可申請(qǐng)DBA協(xié)助絮姆。如果項(xiàng)目規(guī)模大到一定程度醉冤，出現(xiàn)性能瓶頸問題是很正常的，這時(shí)專業(yè)DBA的作用才開始突顯篙悯，且會(huì)在其中扮演一個(gè)非常重要的角色蚁阳。
總之，DBA應(yīng)該是在被需要時(shí)出現(xiàn)鸽照，而不應(yīng)該被強(qiáng)制需要螺捐。
我的項(xiàng)目開發(fā)思路非常明確，關(guān)于團(tuán)隊(duì)矮燎，人越少越優(yōu)秀越好定血，人員明確分工；關(guān)于開發(fā)模式漏峰，前端糠悼、后端、數(shù)據(jù)庫明確分工浅乔。在項(xiàng)目規(guī)模倔喂、工作量允許的范圍內(nèi)人越少越好、涉及合作的部門越少越好靖苇，以便統(tǒng)一管理控制席噩，節(jié)約溝通協(xié)調(diào)的成本。開發(fā)過程中的規(guī)范和約定采用大一統(tǒng)的方式贤壁，嚴(yán)格限制脫離中央管控的腳本或代碼出現(xiàn)悼枢。
