將帶有格式的文本保存到資料庫中的方法/步驟：
1、在jsp中，頁面的帶有格式的文本內容外面用一個大的標簽，給定表簽名。
2、頁面做提交的時候用上面的表簽名點innerHTML的方式來獲取頁面帶有標簽和樣式的內容。
3、將上面取得的內容作為一個字元串保存到資料庫即可，下次把資料庫里的內容直接輸出到頁面就可以了。
對於要輸出到word里保存樣式的方法也是類似的，只是需要去看一下word解析文本的方式與jsp有何區別，在輸出到word的時候做一下變換即可。
❷ 什麼是文本資料庫與關系資料庫之間有什麼聯系和區別
資料庫，是經過優化的存儲格式，一定比文本文件效率好，因為結構化處理的關系，可以很好地應對如搜索、匹配等操作；
而文本，表面看起來簡單，但是，隨著量的增加，一旦達到某個量級，幾乎就不可用了。
至於CPU，資料庫比文本文件的方案更加可控，更安全。
❸ 大規模文本檢索應當用什麼資料庫
是的，大規律檢索是不能通過資料庫的。
檢索的時候不能通過資料庫的查詢來完成。
這個東西涉及到搜索引擎的相關技術。
你可以寫一個小程序試試，假設每篇文章 2000個漢字，有500萬篇，都存入資料庫，你檢索一下試試？
這涉及到分詞技術，分詞索引，分詞的反向索引..
這些技術通常都是保密的。要不然google，網路它們也不會這么有實力，就因為掌握到了這些技術。
之所以這么麻煩，都因為中文語法的特殊性...
❹ 如何建立文本資料庫
這個如果要自己管理數據的話還是挺有難度的。
不過借用資料庫也許可以折中一下，把每個文檔的數據放到資料庫的一個欄位中，然後用like '%...%'匹配。（下策^_^）
推薦使用桌面搜索
❺ 文本文件導入到資料庫中的幾種方法
大型的資料庫開發中常常遇到數據源是平面文件（如文本文件）的情況，對於這樣的數據源，無法使用資料庫對其數據進行有效的管理，另外也無法使用sql語句對其進行查詢和操作，所以當務之急就是將這些平面文件導
入到資料庫中，然後就可以對其進行高效的操作了。
下面介紹幾種常見的數據導入的方法，希望能夠給大家啟迪。另外，本文所涉及到的資料庫均為ORACLE資料庫，其實對於其他資料庫而言，方法類似。
一、Sql*:Loader
該方法是Oracle資料庫下數據導入的最重要的方法之一，該工具由Oracle客戶端提供，
其基本工作原理是：首先要針對數據源文件製作一個控制文件，控制文件是用來解釋如何對源文件進行解析，其中需要包含源文件的數據格式、目標資料庫的欄位等信息，一個典型的控制文件為如下形式：
LOAD DATA
INFILE '/ora9i/fengjie/agent/data/ipaagentdetail200410.txt'
TRUNCATE （也可以用append替換TRUNCATE）
INTO TABLE fj_ipa_agentdetail
fields terminated ","
trailing nullcols
( AGENT_NO char,
AGENT_NAME char,
AGENT_ADDRESS char,
AGENT_LINKNUM char,
AGENT_LINKMAN char
)
其中，INFILE '/ora9i/fengjie/agent/data/ipaagentdetail200410.txt'指明所要導入的源文件，其實源文件也可以直接通過命令行來輸入獲得 ，fj_ipa_agentdetail為目標表的名字，fields terminated ","是指源文件的各個欄位是以逗號分隔，trailing nullcols表示遇到空欄位依然寫入到資料庫表中，最後這5個欄位是目標資料庫表的欄位結構。通過上面這個典型的控制文件的格式分析可知，控制文件需要與源文件的格式信息一致，否則導入數據會出現異常。
除了控制以外，sql*loader的還需要數據文件，即源文件。根據格式的不同，源文件可以分為固定欄位長度和有分隔符這兩大類，這里將分別說明這兩種情況：
固定欄位長度的文本文件
就是每個欄位擁有固定的欄位長度，比如：
602530005922 1012
602538023138 1012
602536920355 1012
602531777166 1012
602533626494 1012
602535700601 1012
有分隔符的文本文件
就是每個欄位都有相同的分隔符分隔，比如：
1001,上海長途電信綜合開發公司,南京東路34號140室
1002,上海樺奇通訊科技有限公司,武寧路19號1902室
1003,上海邦正科技發展有限公司,南京東路61號903室
對於上述兩種文件格式sql*loader均可以做處理，下面就前面那個固定長度的文本來舉例說明：
由於該文本只有兩個欄位，一個為設備號，一個是區局編號，兩者的長度分別為20和5，那麼可以編制控制文件如下：
LOAD DATA
INFILE '/ora9i/fengjie/agent/data/ipaagent200410.txt'
TRUNCATE
INTO TABLE fj_ipa_agent
( DEVNO POSITION(1:20) CHAR,
BRANCH_NO POSITION(21:25) CHAR
)
其中，'/ora9i/fengjie/agent/data/ipaagent200410.txt'為該文件的完全路徑，POSITION(M:N)表示該欄位是從位置M到位置N。
對於有分隔符的數據文件，前面已經有一個例子，這里就不再贅述了。總之，使用Sql*Loader能夠輕松將數據文件導入到資料庫中，這種方法也是最常用的方法。
二、 使用專業的數據抽取工具
目前在數據倉庫領域中，數據抽取與裝載（ETL）是一重要的技術，這一技術對於一些大的數據文件或者文件數量較多尤其適合。這里簡單介紹目前一款主流的數據抽取工具 ――Informatica。
該工具主要採用圖形界面進行編程，其主要工作流程是：首先將源數據文件的結構（格式）導入為Informatica里，然後根據業務規則對該結構進行一定的轉換(transformation)，最終導入到目標表中。
以上過程僅僅只是做了一個從源到目標的映射，數據的實際抽取與裝載需要在工作流（workflow）里進行。
使用專業的數據抽取工具，可以結合業務邏輯對多個源數據進行join,union,insect等操作，適合於大型資料庫和數據倉庫。
三、 使用Access工具導入
可以直接在Access里選擇『打開『文本文件，這樣按照向導來導入一個文本文件到Access資料庫中，然後使用編程的方法將其導入到最終的目標數據 庫中。
這種方法雖然煩瑣，但是其對系統的軟體配置要求相對較低，所以也是有一定的使用范圍
❻ 可以寫一個文本文檔作為資料庫嗎怎麼寫這樣的資料庫
文本無法作為資料庫.如果只是想作為數據的載體,還是可以的.
❼ 如何將文本文件中的數據寫入資料庫中
你先將文本文件按換行符的分開讀到一個字元竄變數中去，name:=(str1,0,4),加到資料庫中去呀。
比如：str1:='張某；19；一(1)',然後就分化這個字元竄，將他逐個加到資料庫中去呀
❽ 文本資料庫是什麼
文本資料庫是包含對象文字描述的資料庫。通常，這種詞描述不是簡單的關鍵詞，而是長句子或短文，如產品介紹、錯誤或故障報告、警告信息、匯總報告、筆記或其他文檔。通常，具有很好結構的文本資料庫可以使用關系資料庫系統實現。
❾ 怎樣將文本文件變成資料庫文件
文本文件是非格式化文件
資料庫文件，例如mdb文件，是標准格式化文件
沒有辦法直接轉換
你可以自己寫代碼解析文本，寫入資料庫
❿ 誰幫忙解釋一下「文本資料庫」
ctb論壇就採用了
php+txt架構
一、CTB的歷史
ctb是16hot在01年底牽頭，由我和winnet參與，將整個結構搭建了起來。結構是16和winnet設計，02年底我實現了大部分功能，後來Felixsun和ccxx加入，並由ccxx實現了更多的功能。在03年初的時候，整個論壇是比較成型了。
具體來說，ctb應該在04年初基本停頓了，一直沒有什麼新的比較大的改動。
從03年以來我就沒有負責過，都是以jivi為首的愛好者在維護吧。
我也有3年左右沒有來過這里了，也對不住ctb的忠實的用戶和愛好者。在此向大家道歉了！真誠的道歉，因為雖然很少來這里，但還是覺得這里是自己的家。
二、說一下我吧
寫ctb基本都是在上大學的時候，03年畢業後，可以說對ctb沒有進行過改動和維護。首先是工作比較忙，沒有了更多的業余時間；其次是寫ctb的文本代碼編寫，就象旅行說的一樣，太讓人抓狂了，不象sql程序那樣，不象桌面程序那樣行雲流水。
畢業後，和16商量過，計劃開發mysql的論壇，也由於種種原因沒有實施計劃。可能是比較懶的緣故吧。自從php5出來後，我對sqlite是比較看好的，認為sqlite的出現基本結束了php的文本程序的歷史。也寫了一段sqlite的php論壇，而且基本功能也成型了，但由於國內sqlite的空間沒有成規模和自己比較懶的緣故吧，這個論壇一直沒有對外發布過。
過年的時候，和雪人計劃合作開發c＃的論壇，已經編寫了雛形代碼，後來由於他去了discuz工作，而擱淺。我想不久，discuz在雪人的努力下應該發布discuz的c＃版本吧。
原來都是憑著興趣，和激情在寫程序，沒有考慮過任何商業運做。把寫代碼當成一種享受，就象在網吧玩游戲的孩子對游戲的樂趣一樣。沒有過多考慮過商業化的東西。如果開始我和16就比較考慮商業化的東西，ctb也應該成為國內最大、最著名的論壇了，呵呵。
現在主要從事工作是c++底層代碼的編寫，以及php業務系統的設計，還有就是c#桌面程序的實現。其他的工作中就用不到了，有興趣的朋友可以來[email protected]聯系我。
三、一些將來的設想
開始的時候是憑激情，平興趣去寫代碼，ctb也可以算國內代碼質量比較好的程序了，但後來隨著接觸各種程序的加多，發現自己存在各種不足，無論是結構設計還是具體代碼優化。不敢說，國內大部分論壇程序的代碼都很差吧，但至少從結構設計上，基本是沒有比較漂亮的。不要提效率如何如何好，呵呵，現在的伺服器，運行各種論壇程序基本效率是差不多的，除非你的程序寫的極差，有各種安全漏洞。越到後來自己越想把代碼結構和具體編寫完美實現，但越來越發現自己的不足，需要學習，需要改進，所以一直沒有徹底的開始和去完成，所以時間也拖到了現在。
從來沒有停止過一種想法，那就是徹底的升級ctb或從新編寫ctb，無論是sqlite或mysql資料庫。還是其他的，但一直由於各種原因而沒有從新徹底的開始。
今天先說這么多吧，在不久的將來，大家會看到我們的新產品的。。。