1樓：逸玲奈奈
講真的，東浩紀本人的原案不就是這個理論的絕佳反例嗎？
東浩紀的書我只草草的過了一遍，如果有失誤的話怪我。
這是今年1月新番的碟片榜，資料庫消費論假如我沒有理解錯的話，應該是講巨集大敘事消亡之後，後現代的阿宅通過萌元素的資料庫來進行消費。那麼1月新番原書使，在形式上毫無疑問是建立在萌元素的資料庫的基礎之上的，但是卷均只有218，震驚，日本阿宅只有不足300人（我們阿宅都是買全套的）國將不將，業界已完。
說白了，資料庫消費只是一種消費傾向而已，只有萌是不夠的。鮑德里亞也好，麥克盧漢也好。他們的理論直接套用到現實之中無疑是有誇張的成分的，這種誇張結合背景來看是可以理解的。
但是我們的東浩紀先生還真去用了，還與我們著名的京都大學文學部哲學科精英發生了這麼大的衝突。
怎麼說呢？我目前還是個高中生，不過好歹也是半個戲文專業的。乙個個就知道欺負編劇，不是會寫字的人都會編故事，不是會編故事的人都會寫劇本，不是會寫劇本的人都會寫原案。
東浩紀連會不會編故事都還另說，哪怕是隨便讀過一本靠譜的故事理論的人都不會把角色和故事分離，我們通常語境下為了表達流暢，會把故事和角色放到不同區域，但實際上角色和故事是一體的，倒不如說角色=故事，我們通常會認為只有充滿大情節的故事才叫故事，這是好萊塢帶來的影響，但歸根到底，故事是更為寬泛的東西。分型不算是通常意義上的萌元素的資料庫型別故事，哪怕是。就東浩紀的個性而言和阿寬和那位女士的組合而言，未必會更好
2樓：
行內人或者天才能夠靠堆積要素做出來的東西，行外人只想撈一把的——沒錯，就是東浩紀——一輩子也就只能看出個堆積要素。
當然，人家一輩子裡不定只撥出多小一丁點用來研究動畫嘞，甚至用研究倆字都抬舉。
通常只不過是
啊我有個觀點——我找找什麼能跟這觀點蹭的上——知名文學作品好像不行——著名娛樂作品好像也不行——隨便找個動畫漫畫得了——反正也找不到更合適的，拉這種底層玩意兒的虎皮無非就是死宅不爽……
這一系列行為的最終結果而已。
三流槍手常幹這事，東浩紀在這群體裡都不算出挑。
3樓：mocona
又乙個萌新發現了東浩紀。
緊接著這位萌新將會依次進入:
「說的很有道理」階段
「在座的動畫都是辣雞」階段
「？？？」階段或「現充社畜不再看動畫」
「東浩紀懂個屁動畫」階段
「東浩紀跟動畫有毛關係」階段
4樓：二月風
東浩紀的兩本動物化的後現代我都看過，並不是完全明白其中的理論
第一本書中提到的資料庫，即萌要素是有很多個設定組成的，而這些設定可以從乙個很廣的資料庫中提取出來，舉乙個簡單的例子，金髮，傲嬌，雙馬尾，這些都是個體要素，都是資料，都是從資料庫中獲取拼接到一起的。這其實就是我們現在看到很多賣人設番劇的典型。比如約會大作戰（我知道很多粉絲會批評我但是約戰絕對是人設強於劇情的典型），每個人物的核心其實都不深，每個人物的屬性都不重複，因為他們是由資料庫中篩選組合出來的。
那麼約戰成功嗎？從商業效應上來說，是，所以東浩紀這一點一定程度上是對的。
最後小南極我吹爆，少女歌劇吹爆
如何避免資料庫不響應導致資料庫執行緒池和業務執行緒池全部掛起？
資料庫讀寫執行緒做超時，哪怕非同步了，堵住了沒有超時一樣會死。再用個守護執行緒去檢測這些排隊的情況，一旦超出閾值就報警吧。在一般業務併發處理中，能丟擲主業務就丟擲主業務，讓主業務能最大併發處理。當然如果在主業務中資料庫響應很慢，而且持續時間很長，那麼無論執行緒池中多少個執行緒 執行緒無線多也不是什麼...
資料庫操作優化如何入手？
ccxxiii 資料庫效能優化 系統CPU，記憶體，磁碟儲存，系統引數，以oracle為例，資料庫SGA，PGA，Process，cursor，session等引數設定優化。對於資料庫SQL優化，首先要規範sql寫法，索引建立，資料生命週期管理等。何以解憂，唯有讀書和實踐。總結幾點 1.善用expl...
資料庫的 Buffer Pool 如何提高並行度？
李晨曦 既然鎖的粒度太大了，最簡單的方法就是減小鎖的粒度就好了，你的實現是全域性鎖，這種肯定慢，執行緒數多的時候甚至比單執行緒還慢。改成範圍鎖或者槽鎖就能夠大幅度提公升效能了，hashtable的每個槽一把鎖，操作page id對映到同乙個槽的page時才會有衝突，否則是沒有鎖衝突的。極端情況下所有...