看不懂寫什麼?
資料要看用途而定
資料要經過分類，分析，統計...變成資訊，然後運用
誰會去看65億萬筆資料??

其實恆河所存沙的數量也是粉可怕滴，有可能超過65億萬粒，但與中國黃河比起來，那又差多了...

albertachen提到：
這些年來 BIG DATA 笑笑笑
有人總計 65億萬筆資料
有笨到用 VIEW 來篩選存取
有笨到用 CURSOR 來篩選存取

Albert 大言簡意駭, 是高來高去的人....
勞駕你落入凡塵, 多說些大眾語言, 多多開示....

幸好你說的狀況, 多多少少經歷過,
得以接通腦海中的經驗, 還能領會你的高語.

先舉的例子來說明:

通常AP人員會這樣下SQL
where substring (SALE_DATE,1,6)='201212'
用欄位運算去符合一個值

有經驗的DBA會改寫成
where SALE_DATE like '201212%'
用資料運算去比對欄位, 使資料庫用到索引

其實用VIEW不是壞事,
壞在VIEW的條件一般下在外層,
導致資料庫無法一開始在主表格就精準取得資料後,
再去串接其他次要表格,
遇此現象, 寧可用TABLE Function 將條件下在內層,
一開始在主表格就精準取得資料.

其實用CURSOR不是壞事,
通常是AP人員寫程式的思維，
往往是一筆一筆處理,
壞在CURSOR每一筆均耗用些許資料庫資源，
在加上沒有開立到好的索引，
對一個長時間的交易而言,
累積起來對資料庫資源是很重的負擔；
遇到此現象, DBA會考量如何下批次的SQL指令.

albertachen提到：

因此 : 很慢很慢
答案 : 要改架構
但是一堆人推推推 BIG DATA
真是好好笑......

往往在DBA看來:
邏輯沒有錯, 就不需改寫架構;
效能差, 應是改寫SQL及建立合適的索引.

在我看來...
BIGDATA 應是用在海量的非結構性資料分析,
卻牛刀小試在解決報表效能問題....

Big Data...
有趣的用詞...
按樓主的用意，是否改一下...用【many data】或者【too many data】會較會用一點..
65億萬筆資料，確實是【很多】資料，而不是【大】資料..
...
SQL 最擅長為這種很多資料的資料庫建置高效率的索引，但首要條件，必須用對你要的讀取資料時所用的指令..
對於擁有65億萬筆資料的Table來說，每次的搜尋，條件必須是明確的，也就是操作資料的前端不可以不給條件或是給模糊的條件...

Cursor是有很明確的使用時機的，所以，設計者應不致弄到用Like這種語法才對..
Cursor的使用也必須視你要求的狀況來執行，如使用單向、或可回頭的捲覆式、屬區域或是全域都很重要..
再者，Cursor的使用，大多不會用在太龐大的資料，因為如此會耗掉太多的資源...除非有萬不得已的原因及理由..

註:
Cursor的使用，以上的說法不太合適於Unix/Linux裡所使用的Informix-4GL的概念。

65億萬筆資料，看似很多，但還得看它的資料結構是否很多欄位，如果只要十來個欄位或是幾個欄位,那這個數額應該還好，若結構屬於很多層的關聯(【含】三階以上的正規劃)，那就有些可觀了...

其實用VIEW不是壞事..
VIEW的使用它本就是一種資料權限的移轉，它好像跟資料多寡不會有絕對的關係(但還是會有關係)..
比方說，同一個資料表，在設計之初，使用了40個欄位，但在使用一段時間後，因時空轉變，它必須分離，把其中15個欄位分離出來，分別弄給兩個不屬的單位去維護，這時你可能用View去作分割的工作，雖然是分割了，它的資料主從關係仍然緊緊的扣住，這是View一個很大的功用...
它的第二個使用時機則是Join主從資料表做出統計表或分類表，以簡化前端開發報表的工作。但單一資料表對自我作關聯再作出統計的作法，不能說沒有，但終是少見，而且這樣的作法應是規劃上出了問題的資料表...

一個規劃妥善的資料庫，不怕很多的資料，越多是越好才對，因為越能表現其實際的效率...