~楓花雪岳~: 1月 2023

星期一, 1月 23, 2023

[SQL] 計算欄位 - where 條件

之前使用計算欄位來改善效能時，觀念上是建立計算欄位和索引後，where 搜尋條件也必須修改才會觸發計算欄位的 index seek，最近發現即使是維持原 where 條件也會觸發，該文章以 AdventrueWorks 2019 Person.Perosn Table 的 ModifiedDate 欄位來說明

下述 TSQL where 條件，對 ModifiedDate 欄位進行函數轉換，從執行計畫就可以觀察到跑 clustered index scan

SELECT
  BusinessEntityID , 
  ModifiedDate
FROM Person.Person
WHERE (CAST(YEAR(ModifiedDate) AS varchar(4))
	+ RIGHT(REPLICATE('0' , 2) + CAST(MONTH(ModifiedDate) as varchar(2)) ,2))
	= '200901'

建立計算欄位 (YYYYMM) 和對應的 Index 來改善該情況

ALTER TABLE Person.Person ADD YYYYMM AS 
	(CAST(YEAR(ModifiedDate) AS varchar(4))
	+ RIGHT(REPLICATE('0' , 2) + CAST(MONTH(ModifiedDate) as varchar(2)) ,2))
	PERSISTED 
    
CREATE INDEX IX_Person_YYYYMM ON Person.Person (YYYYMM)

實際執行下述兩個 where 條件，都會觸發 IX_Person_YYYYMM index seek

-- 修正 where 條件，改以計算欄位為搜尋條件
SELECT
  BusinessEntityID , 
  ModifiedDate
FROM Person.Person
WHERE YYYYMM = '200901'

-- 維持原本 where 條件
SELECT
  BusinessEntityID , 
  ModifiedDate
FROM Person.Person
WHERE (CAST(YEAR(ModifiedDate) AS varchar(4))
	+ RIGHT(REPLICATE('0' , 2) + CAST(MONTH(ModifiedDate) as varchar(2)) ,2))
	= '200901'

最後來測試不同日期轉換方式，是否也能觸發 IX_Person_YYYYMM index seek

SELECT 
  BusinessEntityID , 
  ModifiedDate
FROM Person.Person
WHERE convert(varchar(6) , ModifiedDate , 112)
	= '200901'

從執行計畫就可以發現完全沒有使用 IX_Person_YYYYMM

基本上還是推薦 TSQL 語法也要一併改寫的作法

星期六, 1月 21, 2023

[Shopify] 寄件者電子郵件驗證

Shopify 聯絡資訊的寄件者 email 需要通過兩種驗證

信箱驗證：會寄一封驗證信到該信箱去，只要點選 mail 內連結就算完成
網域驗證：驗證該信箱所屬網域，Shopify 會提供四組 CName，只要在 DNS 內輸入並驗證就算完成

以下就筆記網域驗證相關

聯絡資訊內完成信箱驗證後，可以注意到下方會有 [您傳送的電子郵件在部分顧客的收件匣的顯示方式可能會有所不同] 該警示

點擊上圖 [檢視電子郵件設定] 後會跳至 [寄件者電子郵件]，可以看到網域狀態還是處於 [待處理] 狀態

點擊上圖 [檢視設定] 按鈕會顯示驗證網域所需的四組 CName 資訊，在 DNS 內輸入這四組 CName 後並等待生效，生效後再按下下圖右下角綠色按鈕 [驗證網域]

沒有驗證網域時，顧客收到的 mail 會有滿滿的 shopify 字樣

驗證後就不會有 Shopify 字樣出現

星期五, 1月 20, 2023

[SSRS] 電子發票 - 報表設計

公司導入電子發票，被要求要能列印 A4、A5 格式，根據電子發票實施作業要點 P12 A5 範例，截圖如下來設計

個人設計是把這兩頁當成兩張報表來設計，第一頁稱呼為主頁，第二頁為明細頁，因為明細頁設計方式會涵蓋主頁，該紀錄會以明細頁為主，歸納明細頁報表重點，分別為

分頁顯示標題列
強迫固定每頁資料筆數
資料表最後橫線
頁數顯示

主頁則是應用到 [強迫固定每頁資料筆數] 和 [頁數顯示] 這兩點而已

星期二, 1月 17, 2023

[SQL] Greatest、Least

SQL Server 2022 新函式 - Greatest、Least，官方文件說明

This function returns the maximum (minimum) value from a list of one or more expressions.

看文字說明是無感，但在該範例中發現亮點 - 跨欄位彙總

SELECT
  P.Name
  ,P.SellStartDate
  ,P.DiscontinuedDate
  ,PM.ModifiedDate AS ModelModifiedDate
  ,GREATEST(P.SellStartDate, P.DiscontinuedDate, PM.ModifiedDate) AS LatestDate
FROM SalesLT.Product AS P
  INNER JOIN SalesLT.ProductModel AS PM ON P.ProductModelID = PM.ProductModelID
WHERE GREATEST(P.SellStartDate, P.DiscontinuedDate, PM.ModifiedDate) >= '2007-01-01'
  AND P.SellStartDate >= '2007-01-01'
  AND P.Name LIKE 'Touring %'
ORDER BY P.Name

在該篇 [SQL] 資料表值建構函式 - 跨欄位彙總也是想達到相同目的，但使用 Greatest、Leaset 可讀性更佳

文件上不支援資料型別說明

The following types are not supported for comparison in GREATEST: varchar(max), varbinary(max) or nvarchar(max) exceeding 8,000 bytes, cursor, geometry, geography, image, non-byte-ordered user-defined types, ntext, table, text, and xml.

The varchar(max), varbinary(max), and nvarchar(max) data types are supported for arguments that are 8,000 bytes or below, and will be implicitly converted to varchar(n), varbinary(n), and nvarchar(n), respectively, prior to comparison.

For example, varchar(max) can support up to 8,000 characters if using a single-byte encoding character set, and nvarchar(max) can support up to 4,000 byte-pairs (assuming UTF-16 character encoding).