|
數(shù)據(jù)科學的歷史、開拓者和現(xiàn)代趨勢隨著數(shù)據(jù)科學的發(fā)展，其他相關專業(yè)出現(xiàn)了下降趨勢，如統(tǒng)計學和計算機科學。谷歌的公開數(shù)據(jù)(見http:///1aF8D5T)如下 自2010年以來，數(shù)據(jù)分析師的數(shù)量不斷增加。 自2005年以來，統(tǒng)計學家的數(shù)量有所減少。 自2005年以來，計算機科學家的數(shù)量有所減少。 自2012年以來，數(shù)據(jù)科學家的數(shù)量激增。 你可以在LinkedIn或Indeed上找到其他的公開數(shù)據(jù)(每個招聘廣告的申請人數(shù))，不過這個數(shù)據(jù)跟招聘市場相關。 其他類似的數(shù)據(jù)顯示，所有傳統(tǒng)領域的人數(shù)都在減少，比如六西格瑪、數(shù)據(jù)挖掘、統(tǒng)計學、運籌學等。谷歌數(shù)據(jù)表明，在2011年左右大數(shù)據(jù)開始出現(xiàn)并呈指數(shù)增長趨勢，到2013年大數(shù)據(jù)比數(shù)據(jù)挖掘和六西格瑪更流行了。同樣也是根據(jù)谷歌數(shù)據(jù)，盡管大數(shù)據(jù)的崛起引人注目，但開始于2006年對“分析”這個關鍵詞的搜索量更為壯觀。在2012年搜它的人數(shù)逐漸減少，但仍然比大數(shù)據(jù)高出6倍。 當然，在2000年，許多專業(yè)人士(包括我)，做了統(tǒng)計學、運籌學、計算機科學、六西格瑪、精算學、生物統(tǒng)計學，或一些其他的狹義定義的“分析類”活動，積累了豐富的經(jīng)驗、領導能力、廣泛的知識、敏銳的商業(yè)頭腦、跨越許多領域的專業(yè)知識。因此他們的職位頭銜經(jīng)歷了演變，但他們都有共同點：數(shù)據(jù)分析行業(yè)從業(yè)者。同時，數(shù)據(jù)和現(xiàn)代數(shù)據(jù)架構的發(fā)展，如MapReduce，影響了所有行業(yè)，成為許多專業(yè)人士的共同特性和必備。 注意 數(shù)據(jù)科學家比數(shù)據(jù)挖掘更廣泛，包括數(shù)據(jù)集成、數(shù)據(jù)采集、數(shù)據(jù)可視化(包括儀表盤)和數(shù)據(jù)架構。數(shù)據(jù)科學家還須度量數(shù)據(jù)科學活動的投資回報率。 統(tǒng)計學將會復興很多人都說統(tǒng)計學會消亡，有些主要的統(tǒng)計學家自己也說統(tǒng)計學會消亡。我相信統(tǒng)計科學最終會復興，但它會更多地應用于大數(shù)據(jù)，并適應于大數(shù)據(jù)，且由更少的模型驅動。它將與計算機科學、預測模型、數(shù)據(jù)挖掘、機器學習、運籌學和六西格瑪?shù)哪承┓矫妫约皵?shù)據(jù)庫架構結合在一起，被歸納稱為數(shù)據(jù)科學、業(yè)務分析、決策科學、數(shù)據(jù)情報、分析學，或其他一些尚未被創(chuàng)建或重復使用的術語。我們現(xiàn)在正處于分析學革命的中間階段。 特別是，像我這樣的人，雖然有一個新的職位頭銜——數(shù)據(jù)科學家，但仍然做統(tǒng)計學兼職，有時甚至涉足前沿的理論統(tǒng)計學。對我而言，我已從業(yè)25年之久，一直使用那些在1750年被認為太復雜、計算能力不夠而被拋棄的，但是足夠健壯的技術。在1750年，由于當時計算能力的缺乏，導致了1800年左右一批新穎的、對數(shù)學友好的技術出現(xiàn)，它們具有簡單的公式、方程形式，如最小二乘回歸。這個框架一直延續(xù)至今，可能是導致傳統(tǒng)統(tǒng)計學家人數(shù)減少的原因，現(xiàn)在大數(shù)據(jù)的健壯性比以往任何時候都更重要，當在分布式系統(tǒng)中(在有MapReduce的云中)幾分鐘就可以處理10億字節(jié)的數(shù)據(jù)時，計算的復雜度將不再是問題了。同時，大多數(shù)現(xiàn)代科學家、地理學家、醫(yī)生、計量經(jīng)濟學家、運籌學專業(yè)人士、工程師等都具備較好的應用統(tǒng)計知識。然而，軟件工程師和計算機科學家有時會像記者一樣忽略或誤用統(tǒng)計科學，如開發(fā)的系統(tǒng)里(例如，推薦引擎)有大量未被發(fā)現(xiàn)的虛假評論和欺詐行為。最終，統(tǒng)計科學將開始踏足這些領域。 有人說，大多數(shù)數(shù)據(jù)分析師都是統(tǒng)計學家。在我看來，數(shù)據(jù)分析師是一個初級頭銜，通常是一個有工學學士學位或文學學士學位的人。統(tǒng)計學家有更多的理論背景，在大數(shù)據(jù)出現(xiàn)之前就使用以前開發(fā)好的數(shù)據(jù)模型，并且擁有碩士或博士學位。每天編寫SQL查詢和報告的人是數(shù)據(jù)分析師。 我不當統(tǒng)計學家的部分原因是因為美國統(tǒng)計協(xié)會：它改變了統(tǒng)計學家這個關鍵詞的意義，這限制了統(tǒng)計學家的發(fā)展前景，使其狹窄且單一，只與醫(yī)藥行業(yè)、政府(調查、人口普查、政治事務)、小數(shù)據(jù)(統(tǒng)計學家的大部分收入來源)相關。在過去15年里，該協(xié)會一般不參與或跟隨基于大數(shù)據(jù)的新的統(tǒng)計革命。作為一名比利時公民，我可以對比利時統(tǒng)計協(xié)會說同樣的話。所以這一趨勢不僅限于美國，而且也不僅限于(美式)英語國家，還包括法語和荷蘭語國家，以及其他語種國家。 統(tǒng)計學家應該非常熟悉計算機科學、大數(shù)據(jù)和軟件——1萬變量的10億行數(shù)據(jù)，對真正的統(tǒng)計學家應該是小菜一碟。在云中(甚至在筆記本電腦上的流數(shù)據(jù))，這個數(shù)據(jù)量都能夠快速處理。第一步是縮減數(shù)據(jù)，即使你必須保存所有的觀測值和變量，仍然可以縮減數(shù)據(jù)。一個優(yōu)秀的計算機科學家也能生成置信區(qū)間：你不需要因此而成為一名統(tǒng)計學家，只需會使用本書后面討論的分析橋第一定理即可。計算機科學家和統(tǒng)計學家之間的區(qū)別變得越來越小和模糊。但無須擔心，雖然你在學校沒有學到這些知識(統(tǒng)計學的課程)，你仍然可以在網(wǎng)上學習。 歷史與開拓者現(xiàn)在，讓我們來看看數(shù)據(jù)科學的歷史，以及一些在分析學和數(shù)據(jù)科學領域堪稱先驅的公司。首先，看一看從20世紀80年代末開始流行的關鍵詞，和對2022年的一個預測。 1988年的關鍵詞：人工智能。另外還有：計算統(tǒng)計學、數(shù)據(jù)分析、模式識別、規(guī)則系統(tǒng)。 1995年的關鍵詞：網(wǎng)絡分析。另外還有：機器學習、商業(yè)智能、數(shù)據(jù)挖掘、投資回報率、分布式架構、數(shù)據(jù)架構、量化、決策科學、知識管理、信息科學。 2003年的關鍵詞：業(yè)務分析。另外還有：文本挖掘、非結構化數(shù)據(jù)、語義網(wǎng)、自然語言處理(NLP)、關鍵績效指標(KPI)、預測模型、云計算、升力、收益率、NoSQL、商業(yè)智能(BI)、實時分析、協(xié)同過濾、推薦引擎和移動分析。 2012年的關鍵詞：數(shù)據(jù)科學。另外還有：大數(shù)據(jù)、分析學、軟件即服務(SaaS)、按需分析、數(shù)字分析、Hadoop、NewSQL、內存數(shù)據(jù)分析、機器對機器(M2M)、傳感器數(shù)據(jù)、醫(yī)療保健分析、效用分析、數(shù)據(jù)治理、列數(shù)據(jù)庫。 2022年的關鍵詞：數(shù)據(jù)工程。另外還有：分析工程、數(shù)據(jù)管理、數(shù)據(jù)整形、優(yōu)化的藝術、優(yōu)化科學、優(yōu)化工程、業(yè)務優(yōu)化、數(shù)據(jù)智能。 這些里程碑讓我們對如何利用數(shù)據(jù)有更通用、更全局、更全面的理解。大約開始于1995年的大數(shù)據(jù)運動，谷歌是最重要的貢獻者之一。谷歌通過引入谷歌文件系統(tǒng)、MapReduce，解決了傳統(tǒng)的分布式系統(tǒng)/數(shù)據(jù)庫管理系統(tǒng)(DBMS)的數(shù)據(jù)庫存儲容量限制。(人們經(jīng)常在2003年至2006年期間的行業(yè)會議上討論谷歌的Bigtable大表方案。)然后是HBase和Hadoop分布式文件系統(tǒng)(HDFS)。除了谷歌，雅虎和Facebook也對Hadoop和開源社區(qū)做出了重大貢獻，推動了技術進步。 專注于分析的先驅公司，有以下26家，可以在它們各自的維基百科頁面，找到很多有趣的歷史資料。(警告：這些網(wǎng)頁，比如維基百科主題頁面，包含商業(yè)內容，編寫者是有利益沖突的人、內部人士或與這些公司利益有關的人。)
此列表重點關注已經(jīng)有一定歷史的大型數(shù)據(jù)分析公司。在過去幾年，無數(shù)的參與者如雨后春筍般涌現(xiàn)，特別是在MapReduce生態(tài)系統(tǒng)行業(yè)。 現(xiàn)代的趨勢在新技術方面，很多當今技術都跟大型分布式數(shù)據(jù)庫的集成分析有關。要讓數(shù)據(jù)架構師、工程師和數(shù)據(jù)科學家互相溝通，并做二選一的轉變——以前是“數(shù)據(jù)到分析”(傳統(tǒng)數(shù)據(jù)科學方法)，現(xiàn)在是“分析到數(shù)據(jù)”(是受數(shù)據(jù)架構師和數(shù)據(jù)庫公司青睞的更為現(xiàn)代的方法，因為它的速度更快)。分析到數(shù)據(jù)，意味著分析是在數(shù)據(jù)庫或數(shù)據(jù)存儲環(huán)境里就近進行的，而不是把數(shù)據(jù)下載到本地分析它。這減少了多個數(shù)據(jù)庫用戶的情況下大量冗余下載的必要。在本章的最后一節(jié)中可以讀到更多相關的細節(jié)。 當然，這歸結為在數(shù)據(jù)庫里或就近位置，運用正確而先進的分析工具(不只是提取(Extract)、轉換(Transform)和加載(Load)方面，簡寫為ETL)。當分析是在數(shù)據(jù)庫內部進行時，有時被稱為內存數(shù)據(jù)分析。它是一種更為強大的“分析到數(shù)據(jù)”的形式，是將分析集成和嵌入到數(shù)據(jù)庫架構中，且主要在快速存儲器(內存)中進行，有時還會使用多個服務器。但其中一個問題是，現(xiàn)代數(shù)據(jù)庫處理涉及更復雜的編程語言，而現(xiàn)在大多數(shù)人還在使用SQL，要他們改變舊習慣很難。因此，像Pivotal這樣的先驅公司發(fā)明了一種名為Fast SQL的系統(tǒng)，使那些習慣SQL的程序員不需要學習新的、更加復雜的語言，并且代碼優(yōu)化是在Hadoop(一種分布式架構)下運行的。 其他現(xiàn)代趨勢包括自動化的機器到機器實時通信，在高頻交易策略或大規(guī)模競價系統(tǒng)里都有使用。一個例子是eBay基于谷歌的點擊付費關鍵詞過去的效果(當歷史記錄可用時)，或對沒有歷史記錄的新關鍵詞分析計算其得分，每天實時更新1 000萬個關鍵詞出價。這些機器到機器的通信都是通過API或AaaS(分析即服務，按需求提供)。API調用無非是HTTP請求(實際上，大多數(shù)情況下都是HTTPS請求)，通過查詢字符串參數(shù)(用XML格式編碼的鍵/值對)，指定所需的服務類型(如關鍵詞的價格和數(shù)量的預測)。 此外，現(xiàn)代數(shù)據(jù)如此不同和獨特是因為它的多樣性(有時是Twitter推文的非結構化格式，有時是來自移動設備或傳感器的結構化良好的數(shù)據(jù))、產(chǎn)生速度和數(shù)量，這使得傳統(tǒng)的統(tǒng)計分析并不總是那么合適。 概括說，下面這些都是數(shù)據(jù)科學現(xiàn)代趨勢的特征。
最后提一下Perl，它是偉大的編程語言，5年前比較流行，卻是現(xiàn)代編程環(huán)境的犧牲品。它已經(jīng)被Python及它的分析和圖形庫取代。雖然Perl非常靈活，且無須專注于代碼的編寫，但Perl程序維護困難且成本高。Perl沒能在現(xiàn)代靈活而精簡的環(huán)境中存活下來。也有些人說，最優(yōu)秀的分析工具Excel也會消亡，但我并不這么認為?，F(xiàn)代版本的Excel使用云服務，從互聯(lián)網(wǎng)上獲取數(shù)據(jù)，并將其存儲在多維數(shù)據(jù)表里。 最近的問答討論最近我與不同社區(qū)的數(shù)據(jù)架構師進行了以下討論，特別是(但不僅局限于)同LinkedIn上數(shù)據(jù)倉庫研究所(TDWI)的小組成員進行討論。他們闡述了一些在新的分析革命完成之前，仍然需要解決的挑戰(zhàn)。以下是數(shù)據(jù)架構師和數(shù)據(jù)庫管理員詢問的幾個問題，以及我的答復。這些問答跟在SQL查詢中優(yōu)化連接操作有關，或干脆跟SQL無關。一些現(xiàn)代數(shù)據(jù)庫提供了許多功能，包括哈希表連接和可以由最終用戶進行微調的查詢優(yōu)化程序。該討論說明了數(shù)據(jù)科學家、數(shù)據(jù)架構師和業(yè)務分析師之間的沖突。它還涉及許多創(chuàng)新的概念。 問題：你說SQL的瓶頸之一是用戶寫查詢是通過3個連接實現(xiàn)的，這些查詢何時可以分成兩個查詢，每個查詢兩個連接?你能詳細說明嗎? 答案：通常，我寫SQL代碼的方式是將它嵌入到一種編程語言里，如Python，且在內存中儲存我需要的所有查找表，如哈希表。所以我很少有做連接操作，當我這樣做時，它頂多只是兩個表格。 在一些(罕見的)情況下，查找表太大，而無法放入內存中，所以我使用抽樣的方法，且使用子集和聚合規(guī)則。一個典型的例子是，你的數(shù)據(jù)集(如網(wǎng)頁日志文件)的一個字段是一個用戶代理(即瀏覽器，簡稱UA)。如果你有更獨特的UA數(shù)據(jù)，在內存中裝不下，但只要你保留1 000萬個最受歡迎的UA，并把2 000萬個罕見的UA分到幾百萬類別里(基于UA字符串)，在大多數(shù)應用中能得到很好的結果。 作為一個算法專家(不是SQL專家)，我花了幾分鐘通過Python中的哈希表(使用自己的腳本模板)，做了一個高效的四表連接。我所做的絕大部分都是進階分析，而非數(shù)據(jù)庫聚合：它們涉及先進的算法，但在Python中編碼很簡單，如隱性決策樹。總之，對于非專家級SQL用戶，如業(yè)務分析師，是培養(yǎng)他們寫出更好的SQL代碼，包括復雜的連接，還是培養(yǎng)他們學習將Python跟SQL代碼混合編程，哪種方法更簡單、更有效? 具體而言，我心目中的系統(tǒng)是不需要很頻繁地從系統(tǒng)下載查找表(也許一周一次)，但需要比較頻繁地訪問主表(事實數(shù)據(jù)表)。如果你必須非常頻繁地上傳查找表，那么Python方法將失效，且你的同事會不高興，因為你經(jīng)常下載，從而降低了整個系統(tǒng)的速度。 問題：像你這樣(運行Python或Perl腳本訪問數(shù)據(jù)庫)的人會是數(shù)據(jù)庫管理員(DBA)的噩夢。你不覺得你是給DBA帶來問題的根源嗎? 答案：因為我更擅長Python和Perl而不是SQL，我的Python或Perl代碼是無錯誤、易于閱讀、易于維護、最優(yōu)化、穩(wěn)健和可重復使用的。如果我用SQL編碼，則它的效率是很低的。我所做的大部分工作是算法和分析(機器學習的東西)，而不是查詢數(shù)據(jù)庫。我只是偶爾下載查找表到我的本地機器(保存為哈希表和存儲為文本文件)，因為大多數(shù)情況下每周變化不大。當我需要更新時，我只需提取上次更新后添加的新行(基于時間戳)。在運行處理數(shù)據(jù)量很大的SQL腳本之前，我會進行一些測試，以了解它會消耗多少時間和資源，看看我能否優(yōu)化。我是一個SQL用戶，就像所有的統(tǒng)計學家或業(yè)務分析師一樣，不是一個SQL的開發(fā)者。 但我同意，我們需要找到一個平衡，以盡量減少數(shù)據(jù)傳輸和處理，就近運用更好的分析工具。至少，我們需要能輕松地在非生產(chǎn)數(shù)據(jù)表和系統(tǒng)里部署Python代碼的能力，并且需要合適的磁盤空間(也許200 GB)和內存(至少幾GB)。 問題：你偏好的編程語言是什么? 答案：有些人更喜歡使用腳本語言，而不是SQL。人們認為SQL可能不夠靈活且易于出錯，產(chǎn)生錯誤后沒人注意到，因為連接操作中有Bug。 你可以寫簡單的Perl代碼，易于閱讀和維護。Perl可以讓你把精力集中于算法，而不是代碼和語法。不幸的是，許多Perl程序員寫的代碼晦澀難懂，這使得Perl有了壞名聲(在代碼的維護和可移植性方面)。但是，不一定都是這種情況。 你可以使用多個SQL語句和視圖，把一個復雜的連接分解成幾個較小的連接。你可能認為，數(shù)據(jù)庫引擎會幫你整理這種分解過程，把不那么高效的SQL代碼變得更加有效。至少你可以測試這種方法，看看它是否和一個有許多連接的、單一的復雜查詢的運行速度一樣快。分解多個連接成幾個簡單的語句，讓業(yè)務分析師編寫簡單的SQL代碼，也便于其他程序員重用或維持。 看到一些軟件自動修正SQL語法錯誤(不是SQL邏輯錯誤)是件有趣的事情。這將為很多像我這樣的、非專家級的SQL程序員，節(jié)省很多時間，因為經(jīng)常重復發(fā)生的拼寫錯誤，可以自動修正了。同時，你可以使用圖形用戶界面(GUI)生成合適的SQL代碼，利用大多數(shù)數(shù)據(jù)庫廠商或開放源碼提供的工具，如適用于Oracle的Toad。 問題：你為什么說這些內置的SQL組合優(yōu)化器，對于終端用戶是黑盒技術呢?你認為參數(shù)不能由終端用戶調整嗎? 答案：我總喜歡對我做的事情有所控制，雖然不一定是全部控制。例如，我比較滿意Perl處理哈希表和內存分配的方式。我寧愿用Perl黑盒內存分配或哈希表管理系統(tǒng)，而不是像C語言那樣要自己從頭開始，或更糟糕的是，要編寫一個編譯器。我只是有點擔心黑盒優(yōu)化——我看到過非專家級用戶魯莽地使用黑盒統(tǒng)計軟件而造成的危害。如果我至少有一點控制，我會感覺更舒服，甚至只是簡單地給DBA發(fā)送電子郵件，讓她幫助改善我的查詢語句，讓她幫助解決我的疑問，也許只是微調組合優(yōu)化器，這對所在組織和其他用戶是有必要和有益的。 問題：你不認為你的方法已經(jīng)過時20年了嗎? 答案：結果比方法更重要，只要該過程是可重復的。無論我用什么工具，只要我能打敗競爭對手(或者幫助我的客戶打敗競爭對手)，正如有人曾說過，“如果沒有壞掉，就不要修理它?！庇袝r我使用API(例如，谷歌的API)，有時我用網(wǎng)絡爬蟲收集外部數(shù)據(jù)，有時使用Excel或優(yōu)秀的數(shù)據(jù)庫，有時(不使用任何數(shù)據(jù))依靠肉眼、敏銳分析和直覺，效果都很好。有時我使用統(tǒng)計模型，有時非常現(xiàn)代的架構也是必要的。很多時候，我使用這些技術的組合。 問題：為什么你要問“數(shù)據(jù)到分析”方法是否有意義? 答案：我問這個問題的原因是，因為有些事情一直困擾著我：基于不算過時的觀察(不超過三四年)，我提到的一些做法在數(shù)據(jù)分析領域里已經(jīng)根深蒂固(分析是指機器學習、統(tǒng)計學和數(shù)據(jù)挖掘，而不是ETL)。這也是一個嘗試，看看是否有可能在數(shù)據(jù)科學家和數(shù)據(jù)架構師這兩個非常不同的社區(qū)之間建立一個更好的橋梁。數(shù)據(jù)庫搭建者經(jīng)常(但并不總是)需要數(shù)據(jù)科學家對組織好的數(shù)據(jù)提煉出見解和價值。而數(shù)據(jù)科學家經(jīng)常(但并不總是)需要數(shù)據(jù)架構師建立優(yōu)秀的、快速的、高效的數(shù)據(jù)處理系統(tǒng)，這樣他們就可以更好地專注于分析了。 問題：所以本質上你維護緩存系統(tǒng)，對查找表的本地副本定期進行小的更新。兩個像你一樣的用戶，做著同樣的事情，過一段時間后，會得到兩個不同的副本。你如何處理該問題? 答案：你是正確的，兩個用戶有兩個不同的查找表副本(緩存)，造成了問題。雖然對我來說，我傾向于與其他人分享我的緩存，因此它不像5人在研究5個不同版本的查找表。雖然我是一個高級數(shù)據(jù)科學家，也是一個設計師或架構師，但不是一個數(shù)據(jù)庫的設計師或架構師，所以我傾向于有我自己的、與團隊分享的本地架構。有時我的架構存儲在一個本地的小數(shù)據(jù)庫里，偶爾會存在生產(chǎn)數(shù)據(jù)庫里，但很多時候是作為有組織的普通文件或哈希表存儲在本地驅動器上的，或保存在數(shù)據(jù)庫服務器以外的云里的，但如果數(shù)據(jù)量大，那么數(shù)據(jù)庫到云的距離不會太遠。很多時候，我最重要的“表格”是總結摘要表——要么是很容易用純SQL生成的簡單聚集表，要么是復雜的交易得分(按客戶、日期、商戶或更細的顆粒度評分)，所用的算法太復雜了，以至于使用SQL不能有效地編碼。 我的“緩存”系統(tǒng)的好處是盡量減少耗時，減少對系統(tǒng)內其他人的影響。其缺點是，我需要維護它，并且本質上我是在復制數(shù)據(jù)庫系統(tǒng)本身的進程。 最后，對于研究數(shù)據(jù)的統(tǒng)計學家來說，只要數(shù)據(jù)是幾乎正確的(是指查找表不是最新版本的，而是“緩存”系統(tǒng)中存儲的沒有頻繁更新的)，甚至說數(shù)據(jù)只是抽樣，這都不是問題。通常，收集的數(shù)據(jù)是我們試圖采集和度量的信號的近似——所以數(shù)據(jù)難免混亂。對預測模型來說，不管是從數(shù)量適量的數(shù)據(jù)集(我的“緩存”)，還是原始、最新的數(shù)據(jù)集，或者是認為注入5%噪聲的數(shù)據(jù)，所能得到的投資回報率——在大多數(shù)情況下幾乎相同。 問題：你可以對代碼的維護和可讀性做些評論嗎? 答案：如果某人寫了晦澀的SQL，在他離開公司后，或更糟的是，當SQL移植到不同的環(huán)境(不是SQL環(huán)境)時，這對于要了解原始代碼的新程序員來說，是一場噩夢。如果可讀性好的SQL(也許包含更多語句，更少的高維連接)運行速度和復雜的SQL語句一樣快，這得益于內部對用戶透明的查詢優(yōu)化程序，那么為什么不使用易讀的代碼代替呢?畢竟，優(yōu)化程序應該使這兩種方法是等價的，對嗎?換句話說，如果兩段代碼(一個短但晦澀難懂;一個較長，易于閱讀、維護和移植)具有相同的效率，既然它們本質上會被優(yōu)化器變成相同的偽代碼，那我喜歡較長的版本，因為它的編寫、調試、維護等需要更少的時間。 那些能將難看、晦澀但高效的代碼變成好看、易于閱讀的SQL的工具，如“SQL美化器”，可能有市場。當將代碼移植到不同的平臺時，它是很有用的。雖然在一定程度上，這已經(jīng)存在了，但你可以很容易地對數(shù)據(jù)庫系統(tǒng)所有的查詢或查詢集進行圖表化和可視化。SQL美化器在某些方面類似于一個能把匯編語言轉化成C++的程序——簡而言之，是一個反編譯器或解釋器。 本文作者 Vincent Granville (美國)， 吳博、張曉峰、季春霖參與編譯 End. |
|
|
來自： 昵稱16619343 > 《辦公技能》
