1樓：
資料庫有專門的設計人員DBA
完整的應該是策劃來提供資料字段內容和相互之間的關係，以及描述後續可能的擴充套件情況；
而DBA和遊戲開發者應該相互溝通，DBA設計的資料庫能夠讓遊戲開發者達到策劃的需求（當然，策劃們不一定是專業搞技術的，也許有不是很合理需求技術上達不到），並且能讓遊戲開發者方便、高效的使用資料庫；
遊戲開發者大部分肯定都能使用簡單的資料庫。DBA設計出來的資料庫在前台開發的角度看來，肯定是很零散的資料，遊戲開發者應該會將資料庫做進一步的處理整合，結合DBA設計的資料庫做出乙個方便前台使用的資料庫。
自我認為，策劃是提供資料的內容以及資料之間的相互關係，策劃應該主要考慮資料怎麼能更有效的讓不同的使用者更好、更方便的使用；
DBA主要設計的是能讓伺服器更快、更迅速的運算元據的方式，能讓伺服器更有效的利用空間和計算，並且滿足策劃提出的合理需求和前台開發者的需求；
遊戲開發者應該和DBA共同完成策劃提出的需求；
所以，策劃如果有相關的專業知識，可以參與設計資料庫。但是如果沒有，那就應該提供相關的資料和資料之間的關係，設計資料庫那就應該交給DBA和前台。
2樓：高飛
太多新人會把西文的,換成中文的，因為不注意.卻很麻煩查出資料問題出在那裡.一些策劃老人也會這樣.
最後說一點.我比較推薦策劃自己寫這種工具.因為自己一直用,自己的需求自己最明確.
遇到過很多寫工具的程式.完全不考慮使用者體驗！！！導致工具有了,策劃也很辛苦的用著.
說句難聽的,你離職了換了家公司,導表工具還不是跟你一起走.程式寫的會跟你走嗎？
3樓：連根塞
企劃出式樣，程式設計師執行…
除非企劃同時有程式設計師經驗，否則給不懂行的人設計的結果將非常災難…給文科生講這個格仔不能設0.1是因為資料型別，能花你20min………
經驗相關：大學軟體工程，職業遊戲企劃
4樓：
策劃提供配置表字段，各個字段互相的運算關係，運算公式，時機等等程式負責完成配置表字段，並且幫助缺乏程式技能的策劃補全一些工程向字段。
程式做配置表，會導致功能實現和設計的差異。
策劃做配置表，會導致整個配置表缺乏工程向的特性。
而系統策劃做配置表，在兼具上述缺點的情況下，會導致很多字段缺失。
文案策劃做配置表，在兼具上述所有缺點的情況下，會直接導致返工。
5樓：meta
剛開源了我們的配置系統，stallboy/configgen · GitHub
可供參考
流程上是策劃主導，程式用的時候修改，是個迭代過程。
但實際使用中，大部分還是策劃會詢問程式意見來設立表結構。
使用流程：
新建或修改 csv檔案，csv檔案前2行為header，第一行是中文說明，第二行是英文本段
使用configgen.jar 來生成或完善伺服器客戶端共同使用的config.xml
如果預設的行為不滿足程式需求，則手動修改config.xml，比如修改type，增加ref，enum，range
重複1，2，3流程
6樓：壯士你又懷了
一般我設計的系統功能表結構都是我自己來設計，通常情況下設計出來的表結構都不會對程式造成什麼不好的影響。
因為這個功能哪部分是確定的，哪部分後面是要擴充套件的，我自己心裡有數，交由程式設計師設計往往會對之後的資料填寫和擴充套件上造成麻煩。
如果自己拿不準或者程式認為不合理的，溝通一下各自的邏輯和需求，修正一下就好了。
不過也要看每個專案各自的習慣，有些公司在開發的時候是不需要策劃去考慮這些，這時候一般我也不會強求自己來，和大家保持同步。
7樓：猴與花果山
首先題主應該分清楚資料庫和資料表的區別：
1，資料庫：從策劃的角度來理解更像是乙個存檔檔案，幫你記錄每乙個玩家「可變」的資料，比如你的等級和別人的等級是不同的，所以需要「存檔」，而網路遊戲中的「存檔檔案」就是資料庫。在這塊上，策劃需要做的是設計清楚哪些是需要「存檔」的資訊就好了，這個誰做都是一樣的，我是說不會漏掉什麼東西的，而程式設計師本身會更在意效能問題，所以讓程式設計師去做就好了。
2，資料表：是遊戲邏輯相關的東西，你可以理解為是一種「依據」，資料表是遊戲設計的核心部分，他和「存檔檔案」概念不一樣。由於資料表的使用方式和具體的遊戲邏輯有關係，所以應當是由策劃來設計的。
這一環工作你可以這麼抽象，事情分為兩件：
1）var properties:Object = LoadDataFromTable(table)，寫好LoadDataFromTable這個函式，主要是優化效率等，是程式設計師應該負責的工作，尤其是當表的資料量很大、訪問頻率很高的時候（比如你經常切換場景，而場景資訊來自於某些表）如何去處理好效能問題。
2）properties這個Object應該是有策劃來設計的，table也是策劃設計的，通常properties和table對應的東西應該是一一對映的，這樣程式設計師不需要在這塊做任何邏輯，也就是properties就是記憶體中的table。使用properties肯定是策劃的事兒，程式設計師並不需要關心properties當中具體有些什麼、幹什麼用的。
其實核心在於，遊戲邏輯的東西應該全是策劃去實現的，而框架層、底層的東西則是由程式設計師去實現的，框架層的一些設計最好能由經驗豐富的、並且程式策劃都能做好的人們去做，這樣的框架感覺才會是對的。而資料表這個東西，就是邏輯層的東西，所以應該由策劃設計。
大型網路遊戲的資料庫是怎麼設計的呢？
樹懶學堂 看完這個問題，樹懶君深思熟慮了一番，覺得大致有以下兩種思路 將所有資料先寫入乙個資料庫伺服器。利用SQL的複製功能，同步幾個鏡象資料庫伺服器。當執行查詢的時候，程式自動分流在不同鏡象資料庫裡查詢資料。但是，這個方案有乙個非常明顯的問題 原始資料庫的寫運算元據量衝擊過大時，原始資料庫萬一撐不...
遊戲伺服器使用MongoDB作為資料庫，還有必要使用Redis快取嗎？
圓胖腫 用啥資料庫啊，直接放verticle裡面，速度比用redis快兩個數量級 你想用persistence的話，做乙個非同步的io就是了 說白了還是你的應用太小了。另，MongoDB不是記憶體資料庫，和mysql的NDB儲存引擎一樣，只是把索引檔案放到記憶體中。 徐波 把MongoDB當成MyS...
如何看待第三方 Ingress 遊戲資料庫 RIOT database 及其使用者？
我只是想到了某些站在道德至高點的大佬，一邊標榜自己遵守TOS，一邊又用著類似的系統查殺別人成就。想用用就是了，就別成天說自己有多乾淨。 zrc418 用來針對第三人應當受到譴責。但我真想擁有我自己個人的所有Log啊。還有如果能實現在世界地圖上點亮我走過的Po，那就太棒了。有沒有科技大神能夠指點一下？...