提出問題：

bootstrap-table 可以根據(jù)ajax地址load的json數(shù)據(jù)。這個json數(shù)據(jù)一般就是數(shù)據(jù)庫中查詢的結(jié)果,而數(shù)據(jù)庫中存放的數(shù)據(jù)一般不是用戶友好的，比如數(shù)據(jù)表示一般使用簡潔id或者英文，而將數(shù)據(jù)的具體定義放在其他位置。

舉個例子：

表格1： ***,**** ，類型id

表格1數(shù)據(jù)達(dá)到幾萬行，而數(shù)據(jù)中，類型id是個數(shù)字，類型id的解釋意義在其他表格中存放，一共只有三個類型。

如果我們直接載入表格1數(shù)據(jù)，那么在前端展示中，顯示的類型id是一串?dāng)?shù)字，顯然是不友好的。

解決這個問題的辦法有以下幾種：

1.在客戶端定義對類型id的解釋，某個id對應(yīng)某個中文名稱，這個對應(yīng)關(guān)系實(shí)際就是數(shù)據(jù)庫中的對應(yīng)關(guān)系，但是由于這邊類型只有幾種，可以在代碼中寫死，不需要重新查詢數(shù)據(jù)庫。

? 優(yōu)點(diǎn)：簡單容易實(shí)現(xiàn)，不占用網(wǎng)絡(luò)流量

? 缺點(diǎn)：代碼寫死，以后存在數(shù)據(jù)庫中類型增刪同時(shí)需要修改這部分代碼。如果這樣的代碼一多，維護(hù)成為一件非常可怕的事情。

2.在服務(wù)端就將返回?cái)?shù)據(jù)替換為顯示的格式與意義。這個數(shù)據(jù)庫查詢時(shí)候直接獲取，在服務(wù)器里面修改代碼就可以實(shí)現(xiàn)

? 優(yōu)點(diǎn):客戶端直接顯示即可，簡單

? 缺點(diǎn):占用流量變大，一個字節(jié)的內(nèi)容變?yōu)槎鄠€字節(jié)。

3.將類型id這種數(shù)據(jù)單獨(dú)使用ajax查詢獲取數(shù)據(jù)，在客戶端獲取對應(yīng)關(guān)系

? 優(yōu)點(diǎn):占用流量小，代碼集中，具備自適應(yīng)性來應(yīng)對未來的數(shù)據(jù)改變

? 缺點(diǎn):客戶端需要增加一個ajax查詢，由于該查詢是的數(shù)據(jù)量非常小，也會很快。

?

綜上所述:

我認(rèn)為第三種方法最好，這個不但可以將表現(xiàn)與具體數(shù)據(jù)分隔開，使得展示的代碼更加集中易于修改。并且占用網(wǎng)絡(luò)流量也不多。

?

注意:

請求表現(xiàn)格式的代碼不能直接放入data-formatter中，這樣做的話，會導(dǎo)致每讀一行都會請求表現(xiàn)數(shù)據(jù)，這個數(shù)據(jù)可以放在全局變量里面進(jìn)行復(fù)用,或者放在jquery等閉包中。

轉(zhuǎn)載于:https://www.cnblogs.com/yasmi/p/4911053.html

總結(jié)

以上是生活随笔為你收集整理的使用bootstrap-table等自动使用ajax地址载入数据的插件的数据设计建议的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。