SQL Server Backup Technique

    การใช้งานฐานข้อมูลต่างๆ มีความเสี่ยงที่จะสูญเสียข้อมูล ซึ่งความเสี่ยงในการสูญเสียเกิดจากหลายสาเหตุ เช่น ความเสียหายทาง Hardware, ความผิดพลาดทาง Software Application, ความผิดพลาดในการใช้งานของ user และอื่นๆ ในการสำรองข้อมูลนั้นจึงเป็นสิ่งสำคัญที่ป้องการความสูญเสีย โดยในการทำ backup Database แต่ละรูปแบบนั้น มีความเหมาะสมในการจัดการความเสี่ยง และข้อดี ข้อเสียที่แตกต่างกัน

ใน SQL Server นั้น จะแบ่งเทคนิคออกเป็น 3 รูปแบบคือ
1. Full Backup คือการ Backup Database ซึ่งนับว่าเป็นการ backup ที่ช้าที่สุด แต่ก็จำเป็นที่สุดในการเริ่มต้นทำ backup แบบ อื่นๆเช่นกัน โดยไฟล์ backup ที่จะได้รับนั้นจะประกอบด้วยข้อมูลทั้งหมดของ database ณ ขณะนั้น
2. Differencetial Backup คือการ Backup ข้อมูลในส่วนที่มีการเพิ่มเติมหรือเปลี่ยนแปลงโดยอ้างอิงจาก Full Backup ล่าสุดเสมอ จนถึง ณ ขณะที่เริ่ม process การ backup
3. Transaction log Backup คือการ Backup ทุกๆ ขั้นตอนของการเปลี่ยนแปลงแต่ละส่วนของข้อมูล โดยอ้างอิงจาก Full Backup หรือ Log Backup ครั้งล่าสุด จนถึงณ ขณะที่เริ่ม process การ backup

          ทั้ง 3 รูปแบบ มีความสัมพันซึ่งกันและกัน และสามารถทำงานร่วมกันได้ โดยสามารถเลือกประยุกษ์ใช้ตามความเหมาะสมของขนาดและการเติบโตของ Database

       
      จากรูปสุดท้ายนี้ สีแดงแสดงถึงจุด หรือ ช่วงของเวลาที่สามารถ restore database ไปยัง ณ เวลานั้นๆได้โดยหากวิเคราะห์แต่ละเทคนิคจะมีข้อดี ข้อเสียที่แตกต่างกัน

1. Full Backup สามารถ restore กลับไปยัง ณ เวลาที่ดำเนินการ Backup process ได้เท่านั้น โดยมีข้อดีคือใช้เวลาในการ restore และมีความซับซ้อนน้อยที่สุด โดยไม่จำเป็นต้อง maintain log file

2. Differenctial Backup สามารถ restore กลับไปยัง ณ เวลาที่ดำเนินการ Backup process ได้เท่านั้น แต่ใช้เวลาในการ restore มากกว่า Full Backup และต้องอาศัยไฟล์ 2 ไฟล์ ​และไม่จำเป็นต้อง maintain log file

3. Transaction log Backup สามารถ restore กลับไปยัง ณ เวลาใดๆ ก็ได้ (ระหว่างช่วง Full Backup ครั้งล่าสุด กับ Log Backup) แต่ใช้เวลาในการ restore มากกว่าทั้ง 2 วิธี (อ้างอาจจากเวลา ณ ขณะเดียวกันกับที่ 2 วิธีแรกทำได้) และต้องอาศัยไฟล์อย่างน้อย 2 ไฟล์ ซึ่งต้องเชื่อมต่อกันจนกระทั้งถึงจุดที่ต้องการ restore กลับไป แต่ต้องมีแผนในการ maintain log file

RESTful Web Services

Rest ไม่ใช่มาตรฐานในการสื่อสาร โดยย่อมาจาก  Representational State Transfer ซึ่งใช้ Http protocal ในการสื่อสาร เป็นรูปแบบของ architecture ที่ออกแบบเพื่อลดขนาด ความซับซ้อน และข้อจำกัดของการเชื่อมต่อสื่อสาร ซึ่งอาจเรียกได้ว่าเป็น Lightweight Web Service

SOAP and REST Architecture Overview

SOAP Architecture
- ต้องรับ-ส่งข้อความ XML ตามรูปแบบที่กำหนดไว้โดย SOAP Protocol และต้องมี WSDL ซึ่งเป็นเอกสารประกอบ 
(ซึ่งผู้ใช้ต้องเข้าใจเอกสาร หรือมีเครื่องมือที่เข้าใจเอกสาร)
- Response Message เป็น XML

REST Architecture (Lightweight Web Service)
-       - ใช้ URI เป็นตัวชี้ web service ต่างๆ ประกอบกับ HTTP Method (GET, POST, PUT, DELETE)
-       - ลดความซับซ้อนด้วยการใช้เพียง Http protocol เท่านั้น ในการติดต่อสื่อสาร
-       - Response Message เป็นได้ทั้ง HTML, XML, JSON หรือ Format อื่นๆ โดยกำหนดที่ Header

Why REST is Lightweight Web Service

การเรียกใช้ Web Service ด้วย SOAP Architecture

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

 <soap:body pb="http://www.acme.com/phonebook">

  <pb:GetUserDetails>

   <pb:UserID>12345</pb:UserID>

  </pb:GetUserDetails>

 </soap:Body>

</soap:Envelope>

การเรียกใช้ Web Service ด้วย REST Architecture
http://www.acme.com/phonebook/UserDetails/12345

แนวโน้ม
       บริษัทใหญ่ ๆ เริ่มที่จะเลิกสนับสนุนการเรียกใช้ SOAP Web services และบางบริษัทไม่ได้สนับสนุนตั้งแต่แรก เช่น บริษัทGoogle ได้หยุดการพัฒนาฟังก์ชันใหม่ของ SOAP Search API ตั้งแต่วันที่ 5 ธันวาคม 2549 บริษัท Amazon กำลังจะหยุดการให้บริการAmazon Web services โดยใช้ SOAP กับภาษา Ruby on Rails ส่วนบริษัท Yahoo ไม่เคยสนับสนุนการเรียกใช้ SOAP Web servicesตั้งแต่เริ่มให้บริการต่าง ๆ​

Mirth Connect #1

Mirth Connect เป็น cross-platform HL7 interface engine มีความสามารถในการตัวกลางในการติดต่อสื่อสารระหว่างระบบใดๆ

 โดยมีเป้าหมายหลักคือการ tranform และ transfer ข้อมูลทางด้าน healthcare 

      Mirth Connect เป็น opensorce ที่ถูกพัฒนาขึ้นด้วยภาษา Java ทำให้ผู้ใช้สามารถดัดแปลงเครื่องมือ รวมถึงเพิ่มเติมความสามารถต่างๆเข้าไปได้ โดยโครงสร้างพื้นฐานของระบบดังกล่าวจะเป็น channel-based architecture และมี connectors พื้นฐานให้เลือกใช้ 

- TCP/MLLP

- Database (MySQL, PostgreSQL, Oracle, Microsoft SQL Server, ODBC)

- File (local file system and network shares)

- PDF and RTF documents

- JMS

- FTP/SFTP

- HTTP

- SMTP

- SOAP (over HTTP)

- RTF

รวมถึงมีความสามารถในการดำเนินการกับข้อมูลใน format ต่างๆ ซึ่งเป็น healthcare data 

- HL7 v2.x

- CDA

- CCR

- DICOM

- X12

- Delimited Text

- HL7 v3

- CCD

- XML

- NCPDP

- EDI

- Raw ASCII or Binary

     ในตัวเครื่องมือของ Mirth Connect นั้น ได้ออกแบบให้สามารถใช้งานได้ง่าย โดยใช้ concept drag-and-drop scripting 

ในการสร้าง interface รวมถึงมีหน้า monitor ให้สามารถตรวจสอบ transaction ต่างๆได้แบบ realtime รวมถึง error ต่างๆ ที่อาจเกิดขึ้น 

   ซึ่งตัว Mirth Connect เอง เนื่องจากเป็น open source product จึงยังคงมีการพัฒนา plugin ต่างๆ เพิ่มขึ้นมาเรื่อยๆ เพื่ออำนวยความสะดวก

และเพิ่มประสิทธิภาพ

        จากรูป เป็นตัวอย่างในหน้า dashboard ของ Mirth Connect ซึ่งแสดงรายละเอียดภาพรวมของแต่ละ channel และสามารถ

ดำเนินการเบื้องต้นในการควบคุมการทำ reprocess หรือการ enable/disable process ได้ง่าย

       จากรูป เป็นตัวอย่างหน้าการ coding เพื่อสร้าง logic ของข้อมูล โดยสามารถใช้ภาษา javascript ที่คนทั่วไปคุ้นเคยในการพัฒนา website โดยใช้เพื่อพัฒนา logic ที่ซับซ้อนได้