mysql修正暗碼的三辦法和忘卻root暗碼的處理辦法。本站提示廣大學習愛好者：（mysql修正暗碼的三辦法和忘卻root暗碼的處理辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是mysql修正暗碼的三辦法和忘卻root暗碼的處理辦法正文
【原文地址】New "Orcas" Language Feature: Query Syntax
【原文揭橥日期】 Saturday, April 21, 2007 2:12
上個月我開端了一個貼子系列，評論辯論作為Visual Studio和.NET框架Orcas版本一部門宣布的一些新的VB和C#說話特征。上面是該系列的前三篇貼子的鏈接：
明天的貼子要評論辯論另外一個基本性的新說話特征：查詢句法(Query Syntax)。
查詢句法是應用尺度的LINQ查詢運算符來表達查詢時一個便利的聲明式簡化寫法。該句法能在代碼裡表達查詢時促進可讀性和簡練性，讀起來輕易，也輕易讓人寫對。Visual Studio 對查詢句法供給了完全的intellisense和編譯時檢討支撐。
在底下，C#和VB編譯器則把查詢句法的表達式翻譯成明白的辦法挪用代碼，如許的代碼應用了Orcas中的新的擴大辦法和Lambda表達式說話特征。
在我之前的說話系列貼子裡，我示范了你可以象上面如許聲明一個Person類：
然後我們可使用上面如許的代碼，用一些小我信息來生成一個List<Person>聚集實例，然後應用查詢句法來對該聚集做一個LINQ查詢，只掏出那些姓（last name）的首字母為G的人，按名字（first name）來排序（升序）：
下面查詢句法的表達式在語意上與上面明白應用LINQ擴大辦法和Lambda表達式的代碼是同等的：
應用查詢句法辦法的利益是，成果會是略微輕易讀寫些，這在表達式變得更繁復時特別如斯。
在C#中，每一個查詢表達式的句法從from子句開端，以select或group子句停止。from子句表現你要查詢甚麼數據。select子句則表現你要前往甚麼數據，且應當以甚麼構形前往。
比方，讓我們再來看一下我們對List<Person>聚集的查詢：
在下面的代碼片斷裡，"from p in people"表現了我要對"people" 這個聚集做一個LINQ查詢，我將用參數"p"代表我正查詢的輸出序列的每一個項。我們將參數定名為"p" 這個現實是可有可無的，我完整可以很輕易地將其定名為"o", "x", "person"或我想要的任何名字。
在下面的代碼片斷裡，語句開頭的"select p"子句表現，作為查詢的成果，我要前往一個Person對象的IEnumerable序列。這是由於"people"聚集包括了Person類型的對象，而參數p則代表了輸出序列中的Person對象。是以，該查詢句法表達式的成果數據類型是IEnumerable<Person>。
假設不是前往Person對象，我想前往該聚集中的人的名字，我可以把查詢改寫成如許：
留意下面我不再說"select p"，而是說"select p.FirstName"。這表現我不想前往一串Person對象，而是想前往一串字符串，由Person對象的FirstName屬性（該屬性是個字符串）填充而來。 是以，該查詢句法表達式的成果類型是 IEnumerable<string>。
針對數據庫的查詢句法的例子
LINQ的妙處在於，我可以針對任何數據類型應用完整一樣的查詢句法。比方，我可使用Orcas供給的新LINQ到SQL對象關系映照器支撐，對SQL辦事器的Northwind數據庫停止建模，生成上面這些類（請不雅看我這裡的錄相來進修該若何完成）：
在下面界說好類模子以後（和它與數據庫間的映照關系），然後我便可以寫個查詢句法的表達式掏出那些單價年夜於99元的產物：
在下面的代碼片斷裡，我表現我要對NorthwindDataContext類的Products表停止一個LINQ查詢，NorthwindDataContext類是由Visual Studio orcas的ORM設計器生成的。"select p"表現我要前往婚配我的查詢的一串Product對象，是以，該查詢句法表達式的成果數據類型是IEnumerable<Product>。
就象後面List<Person>查詢句法的例子一樣，C# 編譯器會把我們的聲明式查詢句法翻譯成明白的擴大辦法挪用（應用Lambda表達式作為參數）。在下面的LINQ到SQL的例子的情況下，這些Lambda表達式會被轉化成SQL敕令，然後在SQL辦事器上做運算（如許，只要那些婚配查詢前提的Product記載行會前往到我們的運用中）。促進這個Lambda->SQL 轉化的機制的細節可見於我的Lambda表達式博客貼子的"Lambda表達式樹"部門。
在一個查詢句法表達式開首的"from" 子句和開頭的"select"子句之間，你可使用最多見的LINQ查詢運算符來過濾和轉換你在查詢的數據。兩個最經常使用的子句是"where"和"orderby"。這兩個子句處置對成果集的過濾和排序。
比方，要從Northwind數據庫裡前往按字母降序分列的分類稱號列表，過濾前提是只包含那些含有5個以上產物的分類，我們可以編寫上面如許的查詢句法來用LINQ到SQL對我們的數據庫做查詢：
在下面的表達式裡，我們加了 "where c.Products.Count > 5" 子句來表現我們只需那些含有5個以上產物的分類。這應用了數據庫中產物和分類間的LINQ到SQL的ORM映照的聯系關系。在下面的表達式中，我也加了"order by c.CategoryName descending"子句來表現我要將成果集按稱號降序分列。
LINQ到SQL然後就會在應用這個表達式查詢數據庫時，生成以下SQL：
Select [t0].[CategoryName] FROM [dbo].[Categories] AS [t0]
Where ((
Select COUNT(*)
FROM [dbo].[Products] AS [t1]
Where [t1].[CategoryID] = [t0].[CategoryID]
)) > 5
ORDER BY [t0].[CategoryName] DESC
留意，LINQ到SQL很聰慧，只前往了我們所需的單個字段（分類稱號), 並且它是在數據庫層做了一切的過濾和排序，使得該查詢效力異常高。
先前我指出的一個要點是，"select" 子句表現了你要前往的數據，和這個數據的構形是甚麼。
比方，假設你有個象上面如許的"select p" 子句，這裡p的類型是Person，然後，它就會前往一串Person對象：
LINQ和查詢句法供給的一個異常壯大的功效是許可你界說跟被查詢的數據離開的新的類型，然後用新的類型來掌握查詢前往的數據的外形和構造。
比方，假定我們界說了一個新的AlternatePerson類，內含一個FullName屬性，而不是我們本來的Person類內的離開的FirstName和LastName屬性：
然後我便可以應用上面的LINQ查詢句法來查詢我本來的List<Person>聚集，用上面的查詢句法將成果轉換成一串AlternatePerson對象：
留意看，我們是若何在下面的表達式裡的"select"子句裡，應用我的說話系列的第一個貼子裡評論辯論過的新的對象初始化器句法來創立新的AlternatePerson實例，同時設置它的屬性的。也留意我是若何銜接我們本來Person類的FirstName和LastName屬性，然後將其賦值給FullName屬性的。
對數據庫應用查詢句法投影
這個投影特征在操作從象數據庫如許一個長途數據供給器那邊取回的數據時，會變得難以相信地有效，由於它供給給我們一個優雅的方法，來表現我們的ORM應當從數據庫現實取回哪些數據字段。
比方，假定我用了LINQ到SQL的ORM供給器對Northwind數據庫建模，生成上面這些類：
經由過程編寫上面這個LINQ查詢，我告知LINQ到SQL我要前往一串Product對象：
填充Product類所需的一切字段都將作為下面查詢的一部門從數據庫中前往，由LINQ到SQL orM履行的raw SQL看上去象上面如許：
Select [t0].[ProductID], [t0].[ProductName], [t0].[SupplierID], [t0].[CategoryID],
[t0].[QuantityPerUnit], [t0].[UnitPrice], [t0].[UnitsInStock],
[t0].[UnitsOnOrder], [t0].[ReorderLevel], [t0].[Discontinued]
FROM [dbo].[Products] AS [t0]
Where [t0].[UnitPrice] > 99
在一些場景下，我不須要也不消一切這些字段，我可以界說一個上面如許的新的MyProduct類，只具有Product類具有的部門屬性，和一個Product類其實不具有的額定屬性，TotalRevenue （注： 對那些不熟習C#的，Decimal?句法表現我們的UnitPrice屬性是個nullable值）：
然後我便可以應用上面這個查詢，應用查詢句法的投影功效來結構我要從數據庫前往的數據的外形：
這注解，不是前往一串Product對象，我要MyProduct對象，我只需個中三個屬性被賦值，LINQ到SQL就會很聰慧地調劑要履行的raw SQL語句，從數據庫只前往那三個須要的產物字段：
Select [t0].[ProductID], [t0].[ProductName], [t0].[UnitPrice]
FROM [dbo].[Products] AS [t0]
Where [t0].[UnitPrice] > 99
為誇耀起見，我也能夠填充MyProduct類的第四個屬性，即TotalRevenue屬性。我要這個值等於我們產物今朝的發賣額的總量。這個值在Northwind數據庫中並沒有作為一個事後算好的字段而存在。而是，你須要在Products表和Order Details表間做一個聯系關系，然後盤算出一個給定產物對應的一切的Order Detail 行的總量。
異常酷的是，我可以在Product類的OrderDetails聯系關系上應用LINQ的 Sum 這個擴大辦法，編寫一個作為我的查詢句法投影一部門的乘法Lambda表達式，來盤算這個值：
LINQ到SQL就會異常聰慧地應用上面這個SQL在SQL數據庫裡做運算：
Select [t0].[ProductID], [t0].[ProductName], [t0].[UnitPrice], (
Select SUM([t2].[value])
FROM (
Select [t1].[UnitPrice] * (CONVERT(Decimal(29,4),[t1].[Quantity])) AS [value], [t1].[ProductID]
FROM [dbo].[Order Details] AS [t1]
) AS [t2]
Where [t2].[ProductID] = [t0].[ProductID]
) AS [value]
FROM [dbo].[Products] AS [t0]
Where [t0].[UnitPrice] > 99
在默許情況下，查詢句法表達式的成果的類型是IEnumerable<T>。在下面的例子裡，你會留意到一切的查詢句法賦值是給IEnumerable<Product>, IEnumerable<string>, IEnumerable<Person>, IEnumerable<AlternatePerson>, 和 IEnumerable<MyProduct> 變量的。
IEnumerable<T>接口的一個很好的特點是，完成它們的對象可以把現實的查詢運算延遲到開辟人員第一次試圖對前往值停止迭代(這是經由過程應用最早在VS 2005中C# 2.0 中引進的yield結構來殺青的)時才停止。LINQ和查詢句法表達式應用了這個特征，將查詢的現實運算延遲到了你第一次對前往值停止輪回時才停止。假設你對IEnumerable<T>的成果從不停止迭代的話，那末查詢基本就不會履行。
比方，斟酌上面這個LINQ到SQL的例子：
不是在查詢句法表達式聲明的時刻，而是在我們第一次試圖對成果停止輪回（下面紅箭頭標記的處所），才會去拜訪數據庫和掏出填充Category對象所需的值。
這個延遲運算的行動成果變得異常有效，由於它促進了一些把多個LINQ查詢和表達式鏈在一路的強無力的組合場景。比方，我們可以把一個表達式的成果喂給另外一個表達式，然後經由過程延遲運算，許可象LINQ 到SQL如許的ORM依據全部表達式樹來優化raw SQL。我將在今後的一個博客貼子裡對如許的場景做示范解釋。
若何連忙對查詢句法表達式做運算
假如你不要延遲查詢運算，而是要對它們連忙就履行運算，你可使用內置的ToList() 和ToArray() 運算符來前往一個包含了卻果集的List<T>或許數組。
比方，要前往一個基於范型的 List<T> 聚集的話：
要前往一個數組的話：
在下面兩種情況下，會連忙拜訪數據庫，填充Category對象。
查詢句法在應用尺度的LINQ查詢運算符來表達查詢時，供給了異常便利的聲明式簡化寫法。它供給的句法可讀性異常高，可以針對任何類型的數據（內存中的聚集，數組，XML內容，和象數據庫如許的長途數據供給器，web辦事等等）停止查詢。一旦你熟習這個句法後，你可以在任何處所運用這個常識。
在不遠的未來，我將停止本說話系列的最初一部門，該部門將評論辯論新的匿名類型特征。然後我將轉而評論辯論在現實運用中應用一切這些說話特征的一些異常適用的例子（特殊是針對數據庫和XML文件應用LINQ的例子）。
願望本文對你有所贊助，
Scott
