根據前篇安裝說明與步驟相信各位已經安裝好Fhirbase Server了,接下來就是測試與應用的重要階段,此篇要跟大家解說的是如何運用JASONB使用Fhirbase和FHIR資源。JSONB的工作原理不同:它以二進制形式存儲JSON文檔(這是JSONB名稱來自JSON二進製文件的來源)。以二進制形式,離散值的訪問速度比文本形式中的訪問速度快得多-無需一次又一次地解析JSON文檔。一個文檔僅被解析一次PostgreSQL將VARCHAR值強制轉換為JSONB。不利的一面是,當將原始JSON文檔保存在JSONB中時,無法保留其格式:二進制形式會丟棄空格,但是在大多數情況下,它並不重要。每個FHIR資源都有兩個資料表:一個資料表包含一個資源的當前版本,而歷史資料表包含所有以前的資源版本。如果各位想查詢資料表,可進入Terminal 視窗,利用指令進入DBA模式查詢。也可以透過Pgadmin的Web GUI介面來執行CRUD功能。
指令查詢資料表patient 紀錄
Patient search front 100 |
在執行Fhirbase資料運用前,先來詳細了解一下Jasonb的語法和指令,先了解一下Jason和Jasonb相同的運算符號。
※注意
這些運算符對於
我們以查詢患者'Aaron697'為例,下列語法會產生錯誤:
(ERROR: invalid input syntax for type JSON)
因PostgreSQL有嚴格的類型系統(Type System),因此它不能比較“ Aaron697”(類型VARCHAR)和JSONB值,即使它只是JSONB中的一個字串(String)。為了使此查詢正常工作,我們需要應用雙箭頭運算符(->>),返回VARCHAR而不是JSONB:
正確的語法指令如后:
json
和jsonb
類型都有並行變體。field/element/path提取運算符返回與其左側輸入相同的類型(json
或jsonb
),但指定為returning的類型除外text
,它們將值強制為文本。如果JSON輸入的結構不符合請求,則field/element/path提取運算符將返回NULL而不是失敗。例如,如果不存在這樣的元素。接受整數JSON數組下標的字段/元素/路徑提取運算符都支持從數組末尾開始的負下標。我們以查詢患者'Aaron697'為例,下列語法會產生錯誤:
(ERROR: invalid input syntax for type JSON)
- SELECT resource->'name'->0->'given'->0
- FROM patient
- WHERE resource->'name'->0->'given'->0 = 'Aaron697'
- LIMIT 5;
->>
正確的語法指令如后:
- SELECT resource->'name'->0->'given'->>0
- FROM patient
- WHERE resource->'name'->0->'given'->>0 = 'Aaron697'
- LIMIT 5;
這句語法的意思是取得(Get)resource欄位下第0組的name下的第0組given 'Aaron697'名稱患者最少列出5筆紀錄,知道概念後,我們利用Pgadmin4 Web-GUI介面來測試一下吧!
查詢指令 |
產出的結果 |
謂詞運算符(Predicate Operators)
謂詞運算符可以在任何深度進行檢查JSON值中是否存在特定的值或鍵,並傳回True。和箭頭符號(
->
, #>
, ->>
, #>>
)最大不同的是箭頭符號只使用一個Gin_Index索引,而稱謂符號是如果左側值中包含右側JSONB值,則返回TRUE:@>,如下列範例所示:
左側值中包含右側的HL7及FHIR值則回傳True。
SELECT '[“ FHIR”,“ HL7”,“ FHIRBASE”]' :: jsonb @ > '[“ HL7”,“ FHIR”]' :: jsonb ;
左側值中包含右側姓名Aaron則回傳True。SELECT '{“ name”:[{“ given”:“ Aharon”},{“ given”:“ Aaron”}]}' ::: jsonb @ > '{“ name”:[{“ given”:“ Aaron” }]}' :: jsonb ;
在另外一例,我們可以使用查找所有表明患者符合檢驗值LOINC"72166-2"和長期吸菸SNOMED值"449868002"是吸煙者的觀察值:
SELECT * FROM observation
WHERE (resource @> '{"code": {"coding": [{"code": "72166-2"}]}}'::jsonb) -- LOINC: Smoking status
AND (resource @> '{"value": {"CodeableConcept": { "coding": [{"code": "449868002"}]}}}'); -- SNOMED: Current every day smoker
此查詢大約需要100毫秒才能執行。它的速度非常快,但壞消息是,當表中有更多記錄時,查詢時間將線性增加。發生這種情況的原因是PostgreSQL對該查詢執行了順序掃描,並實際上檢查了每個觀察值是否包含指定條件。\timing
為此我們可在列上創建一個GIN索引...observation.resource來優化查詢。
CREATE INDEX observation_idx ON observation USING GIN (resource);
沒有留言:
張貼留言