1. 如何修改dede內容模型的固化欄位
改模板應該就好了，資料庫里只是一個空欄位，直接改後台目錄下的template目錄下的sofi_add還有soft_edit ，
2. 內存資料庫，Mysql和sqlite，哪個更好
一般，內存資料庫對應磁碟資料庫，而mysql和sqlite通常指的都是磁碟資料庫的兩種不同管理系統。下面分別回答一下內存資料庫和磁碟資料庫優劣，mysql和sqlite優劣。
內存資料庫：
基於內存的具有高效I/O、高並發的資料庫。缺點存儲量有限、可恢復性差。
1.
磁碟資料庫：
基於磁碟存儲穩定、保證數據可恢復性、一致性的資料庫。缺點是實時性不足。
兩種資料庫一般來講不會沖突，沒有一個企業能夠脫離磁碟資料庫，固化的穩定的數據一般都是採用磁碟資料庫。但是，當企業面臨用戶量擴大，並發性、實時性要求不斷提高時，便會藉助內存資料庫。因此，根據你的場合選擇合適的資料庫存儲形式非常重要。對於內存資料庫，其實自己也沒怎麼用過，給你個傳送門：http://dev.yesky.com/418/35355918.shtml
2.
對於mysql和sqlite，我個人覺得目前mysql非常通用，免費開源，學習成本低，應用面廣泛，落地迅速，與各大主流的編程語言都有通用介面。相對較好，sqlite我只在學校時候用過，Σ( ° △ °|||)︴。
一起學習一起進步！
3. redis和各個資料庫之間是怎麼關聯的
沒有直接關聯，按照現在常用的來說，hibernate和mybatis，都是先查出數據，然後放進緩存的，我沒有見過redis和資料庫關聯的。
4. 如何將SQL的執行計劃固化在CACHE
1.獲取普通執行計劃，效果類似於先執行set autot on exp;然後執行sql。
explan plan for your_sql;
select * from table(dbms_xplan.display);
2.獲取具有outline信息的執行計劃，用sqlprofile調優時非常有用，或者用這個執行計劃了解更多oracle內部的hint
explan plan for your_sql;
select * from table(dbms_xplan.display(null, null,'advanced -projection'))
5. NewSQL分布式資料庫發展策略討論
作者 石默研
本文對新一代NewSQL分布式資料庫發展策略中的普遍困擾進行討論，包括雲原生（Cloud Native）與本地部署(On Premise)、HTAP進展方向、分布式與單機需求等分布式資料庫商業與技術發展中難以決策的問題。
1. 困擾
分布式NewSQL資料庫近年來蓬勃興起，其原因顯而易見：切中了業務與數據量不斷增長的用戶對關系型資料庫RDBMS需求，這在傳統RDBMS到大數據的發展階段中，有相當一段時間是空白。同時，隨著互聯網技術的不斷發展與普及，用雲計算模式滿足IT需求似乎已經成為未來 社會 產業互聯網發展的明確趨勢，也就是說，有一種共識：不久的將來，絕大多數產業的IT服務是從公共的、行業的或者私有的、混合的雲計算中心提供的。這一共識又帶來了雲原生（Cloud Native）概念與技術的興起，而分布式NewSQL資料庫自然也應該是雲原生的，這決定了其相當多的產品設計決策應以符合這一趨勢為原則。然而，在當今的現實中，滿足業務與數據量不斷增長的RDBMS需求的用戶，與雲原生的用戶，除了互聯網企業外，大多數情況下，並不重合，需要On-Premise部署的用戶仍然佔有很大比重，這就帶來了第一個困擾：雲原生（Cloud Native）與本地部署(On Premise)對產品發展要求的矛盾。
另一個困擾，是關於HTAP，即交易與分析混合負載。HTAP是當今非常火的一個概念與技術，在交易庫上直接進行分析，而不再是將「數據從交易庫搬下來，挪到另一個資料庫中去」這樣的繁瑣過程。可以毫不誇張的說： 歷史 上規模性企業IT復雜度的相當一部分，都來自於「搬數據」，這導致了數據採集、實時採集、全增量合並、數據傳輸、數據載入、數據建模、數據質量、數據標准、企業級元數據管理等繁雜多樣的技術環節的產生，導致了企業數據分布、數據流向、數據模型、主數據、基礎數據平台、ODS/數據倉庫/數據集市、數據治理等復雜的數據架構設計優化領域，導致了由於多系統大規模數據搬遷而帶來的如數據交換平台之類的復雜調度工程......。咋眼一看，感覺該企業的數據技術好厲害，相關各領域的技術產品好豐富，技術人員的相關技能也好受歡迎。但如果在交易庫就能直接滿足分析需求而不影響生產效能的話，這些復雜高級的技術環節不都成了「自己給自己造了一座山，還說自己爬的好辛苦」？然而，現實卻是，問題並不這么簡單，除了在交易庫中進行分析會影響業務效能外，還有很多原因導致這一現象產生：交易庫並不需要存儲那麼長的 歷史 數據，而分析往往是需要建立在大量 歷史 數據之上的；交易庫的模型往往並不適合分析需求，多數情況下需要重要建模，如非常流行且價值不菲的各行業數倉主題模型；用於交易的OLTP資料庫與用於分析的OLAP資料庫，其技術體系完全不同；以及大型企業已固化的內部業務結構並沒有留給交易/分析整合可實施的可行空間......等等。由於， 歷史 積累的企業級數據體系相當復雜，HTAP的發明者迄今為止都沒有系統表達完全替代數據分析需求、自頂而下重構企業數據體系的架構級策略，而是將產品重點定位在技術優化層面：在交易庫上直接完成實時統計分析，滿足高並發需求且不影響業務效能；或者是為實時分析統計/查詢而建設的數據服務中間平台。然而，即使是暫時沒有這種策略性的意向，在面向AP的產品具體研發中，又會發現明確的界限確實不好把握，隨著一個個具體功能的不斷完善，似乎假以時日，技術上也不是沒有完全替代純OLAP平台的可能性。那麼，HTAP究竟如何定位呢？
再者就是規模化的分布式需求，與小規模的單機資料庫需求（這里指邏輯上的單機）之間的矛盾：分布式資料庫，自然而然是要應對規模化的數據管理需求的，長尾的小規模需求當然不應在產品設計考慮之列，同時，大炮轟蒼蠅經常還打不好；然而，分布式NewSQL資料庫又應該是雲原生的，如果把雲原生的業務含義理解為「全自助」，它應該以支持什麼樣的需求為主呢？現實看來，小規模長尾業務對雲原生資料庫的需求最起碼應該是占據相當大的比重的。顯而易見，如果是大規模的數據管理需求，即使是部署在雲上，DBPaaS的「全自助」是其核心需求嗎？這種規模化的業務，如果是雲上的On-Premise又需要做出哪些方面的改變？從互聯網與雲計算發展的 歷史 來看，「雲自助」，其最核心的商業動機當然包括給用戶側的運維帶來了方便，但更重要的可能是給雲服務運營商應對海量長尾客戶的安裝與運維帶來了極大的成本優勢。這正如銀行的小微及個人消費貸款都要走互聯網線上模式，而重客、大客甚至中小企業信貸仍然是以線下為主的策略一樣，本質是成本問題，而不是客戶方便性問題。於是，矛盾顯而易見：分布式是面向規模客戶的，起碼是中、大型客戶，而雲原生卻有可能、最起碼相當一段時間內是要以長尾客戶為主要服務對象的。
以上困擾實質上，都涉及到了NewSQL分布式資料庫的產品發展策略問題。
2. 討論
問題是客觀而又普遍的，但分析與應對策略往往包含主觀因素：人們的一個決定與決策，很多情況下並不由嚴格推理而來，而是心中已經有一個答案，再來找理由支持它。這里的討論或許也並不能例外。
首先，來看看Cloud Native與On Premise。雲原生本應是資料庫即服務，然而目前真正有規模化數據增長需求的NewSQL應用相當多的情況下卻是付費On Premise與免費On Premise區別，很多互聯網企業的應用也可能只是部署在雲基礎設施上而已，真正的雲原生更多是一些實驗性、嘗試性的需求。但雲原生資料庫在公有雲、行業雲以及大型私有雲上已經逐漸在形成一種意識上的共識，其商業前景不可限量。也就是說，未來的數字化轉型進程中，產業互聯網的資料庫部署，會逐漸向雲基礎設施遷移，長在雲上。它可能是公有雲，也可能是行業雲，也可能是私有雲，它們都是被定義為雲原生NewSQL資料庫的市場范圍。當然，肯定還會有相當一部分資料庫長在雲下，這也不用糾結，將其排除在雲原生市場戰略目標之外即可，就是說，不需要考慮這部分客戶需求對產品規劃的影響，因為前一部分的份額已經足夠大了。這樣看來，以雲原生為目標進行產品規劃的邏輯沒有問題，不過，還是要明確一點：長在雲上的資料庫是不是一定符合我們對「雲原生」的既有理解？這里認為，即使未來，在雲上形成了產業互聯網資料庫市場的主體，需要「全自助」的資料庫即服務可能也是以面向長尾客戶最為迫切、必不可少並且是核心本質，而對中大型以上的需求，「全自助」的意義相對有限，同時比較而言商業模式的轉變或者更關鍵些。那麼，如果是以「長在雲上」為市場目標，似乎可以將其定義為「廣義的雲原生」，同時，只要是「長在雲上」，那麼「雲原生」概念中高彈性、高可用、低成本、快速迭代、存算分離等技術優勢也都能方便獲得。而對「雲原生」策略中「雲原生」一詞的理解不同，對產品規劃決策的影響也應該有所不同：一是目前被認為是On Premise的客戶需求，或許也就是未來「雲原生」主體市場的需求；二是NewSQL資料庫關於雲原生服務的產品策劃，對用戶側「自助」水平的決策或許可以更靈活實用。高水平自助確實可以減輕客戶對IT的依賴程度，但這里認為，雲原生與用戶自行在雲上購買資源進行On-Premise部署相比，最關鍵的價值在於商業模式的改變，能自助多少，不一定是最重要的，因為成為雲服務商後，運營運維的工作只會更多，責任可能會更大，甚至有時連IaaS的運維也需要PaaS服務商兜底。但從一個個客戶的本地服務，變成集中化雲服務，就已經是本質性的模式轉變了。總之，需要就事論事，回到原點，仔細分析後決策，而不是用概念教條的判斷，因為概念本身的定義並不見得准確對應實際的業務需求。
再來看看HTAP，對這個問題，正如在其它文章中表達過的一樣，本文的觀點較為明確。一是隨著計算能力與架構的升級，從技術上講，AP與TP的界限會越來越模糊；另外特別是在雲原生的新世界裡，資料庫的這一特性又猶為重要，因為雲原生的重要作用之一就是要讓客戶盡量擺脫對IT運維的依賴，將越來越多的精力集中到自己的業務發展上來；同時端到端的能力提升對雲原生商業模式的貫徹也至關重要（需要仔細分析下目前DBPaaS的技術要求是否完全符合這一原點的、本質性的動力），過去與純OLAP資料庫的優勢比較糾結在這里也可以得到正面支持；再者，既然架構上已經走向了AP，就很難做到在產品規劃上時刻釐清純AP與混合負載的需求後，再將前者排除在外。於是，以「混合負載滿足部分AP需求」應該是由於投入與階段性市場策略導致的階段性產品規劃，而長遠來講，以一套技術架構滿足大多數需求，應該是雲原生NewSQL資料庫的追求。
接下來，就是關於規模化分布式與小規模單機需求的矛盾了。現在看來，經過上面的討論，這一點已經不是什麼問題了：因為「長在雲上」、從分散服務向集中服務的商業模式轉變就是指廣義的雲原生，而不一定要以小微的、迫切需要全自助的長尾為主流，那麼，雲原生NewSQL資料庫仍然應以規模化分布式為其主體的需求方向，而小規模單機則暫時可以不做為重點來考慮。
最後指出一點，希望也能引發進一步的思考：我們所批判的主機，也聲稱自己是分布式架構，暫且不論其是否客觀，但在現實中主機需要被替代的核心問題並不是有沒有分布式，而是：一、擴展不靈活帶來成本問題：「我只需要擴展一個節點，你卻讓我再買一台主機」；二、不自主可控；三、往往是軟硬體結合的設計策略，包括內存、網路、存儲與IO上的軟硬融合設計，而這一點，是否需要雲原生資料庫從廣義的定義出發進行學習參考，也是需要進一步討論的。
6. sql rownum 固化的作用是什麼呢
rownum 像一個隱藏的欄位，是對結果集的編序排列，始終是從1開始
7. 什麼是sql中的stored proceres
stored proceres 就是存儲過程，就是已經命名的代碼段。
這個和一般編程語言中的方法（函數）類似，可以實現循環、IF判斷、異常處理等等。
8. 固化的表如何查看它的原始SQL
借住客戶端工具
比如mysql，可以使用mysqlfront 選中表 右鍵 有菜單查看 源代碼
9. 對資料庫中表和視圖各是怎麼樣理解的
表是存儲數據的基本單位，在SQL能看到和操作表，視圖是基於表，用查詢語句從一張表或者多張表中查詢數據，為了固化這個查詢，所以把這個查詢做成視圖。
10. 數據的登記
數據的登記是將電子文本及數據信息按照設計的存儲方案進行分類存儲，給它們賦予唯一的標識符，用以證明該文件或數據的身份，使得它能夠在相關領域流轉、管理，避免發生沖突。登記的作用是證明數據與電子文件在存儲系統中的存在。它是電子文本和數據管理的基本要素。從而保證電子文本和數據在生命周期內受到地質資料管理工作的監管和控制。
上述生成、採集、集成、固化、驗收和登記，是地質資料收集的前端控制管理思路下的工作環節。物探數據和各類電子文件產生以後，就要通過程序進行規范採集與及時捕捉，防止漏網；集成是將收集和捕捉到的零碎的電子文件和數據集中管理，如人工地震項目，有數據體、野外工作日記、測繪數據與坐標等，整合相關數據，使互相關聯的文件和數據成為有條理的一個單元，才能符合地質資料「保持文件或數據之間的聯系」精神；通過固化和定位，將電子文本和數據中的信息固定下來，轉化為不可逆的只讀方式；通過登記，將電子文本和相關數據(如地震磁帶數據)正式納入地質資料管理系統中來，並給予驗證碼；驗收，貫穿於多個環節，數據產生被採集後，有專門崗位人員驗收，防止採集人員的採集出錯，以及後期的跟蹤記錄文件的被訪問、被修正過程。
在實踐工作中，勘探開發工作過程中形成的各種數據和電子文件，被接收到數據池，成為數據中心的資源和管理對象，本身就有相關工作程序制約，以保證其完整性和真實性；當這些數據和電子文件被地質資料管理部門接收並運用，成為地質資料，並被作為地質資料進行管理和利用時，數據中心的工作環節是被地質資料管理方認可的。一方面，當地質資料被作為數據中心的數據而接收和保存，地質資料的驗收等程序也應該被數據中心認可。另一方面，當數據中心庫里的數據，被當地質資料吸收共享時，數據中心裡的這些數據的真實性也是應該被地質資料管理部門認可的。或者說，它們原本就是一家，在定製數據保真和驗收等相關工作程序時，就應當共同商定，相互兼顧，統一標准。根據信息化管理趨勢，有條件的單位，可以將地質資料管理和數據中心建設結合起來部署，共同納入企業信息化管理中去，並逐漸形成管理模式。
目前數據中心(也有稱數據銀行的，其意在將數據當成資產)建設，大多數屬於行業、企業、單位、院校自己在做，研究方面也是離散的，從自己所在學科、地質專業、主要職能角度出發，畫地為牢，自說自話，互不相干。宏觀整體性思考有點不足。所以地質勘探開發相關單位或企業，在自己所控制的范圍內，注意源頭數據採集和地質資料管理的前端控制中的以下幾點：
一是兼顧勘探開發工程多個源頭不同數據，統一規定在各源頭將數據一次性採集，多頭共享。避免企業內部數據重復採集。解決勘探資料庫、開發資料庫的數據管理、地質資料管理體系、課題管理體系多頭採集層層匯總的數據不一致，上報及歸檔不及時、基層多頭採集負擔過重等問題；如單井基礎數據，在鑽井工程中一次採集完成，勘探資料庫、開發資料庫、地質資料資料庫都要用這些單井基礎數據，以往是各自安排人員錄入情況，可變為源頭一次錄入後，大家共享。
二是兼顧多頭，統一標准，多點共用。解決由於信息管理與資料管理兩個系統標准不一的問題，避免數據交換、數據匯總分析中出現障礙。
三是兼顧多頭，統一管理，安排崗位。解決信息管理與資料管理數據共享、數據安全多頭設崗問題。
四是兼顧多頭，統一模板，為地質資料與數據中心融合與推廣實施奠定基礎。
五是兼顧多頭，統一服務，解決多方收集資料數據和整理困難。在數據源發生地設立應用平台，統一為信息和資料提供服務。數據採集點採集的數據同時為信息和地質資料管理提供服務，其中為資料服務即根據歸檔要求列印相關數據表和紙質文字材料，拷貝相關數據，這也有容災意義上的異質備份。