โดย Emily Riederer
เวลาเราพัฒนาซอฟต์แวร์ เราก็จะใช้พวก unit tests แล้วก็ service-level agreements (SLAs) เหมือนเป็นคำมั่นสัญญาในเรื่องของ performance และมี interfaces ที่เป็น common symbols และ labels
อย่างไรก็ตาม data tables (ตารางข้อมูล) มันจะเหมือนอยู่กลาง ๆ ระหว่างของที่เป็น service กับการออกแบบ application ทำให้ต้องมีการสื่อสารกับเพิ่มเติมระหว่างฝั่ง data producers กับฝั่น data consumers หรือเราจะเรียกการสื่อสารตรงนี้ว่า “contract” ซึ่งถ้าขาดตรงนี้ไปจะทำให้การคุยกันทั้ง 2 ฝั่งไม่เข้าใจกัน และปัญหาเรื่อง data quality ก็จะตามมา
เราสามารถที่จะมานิยาม และออกแบบส่วน data table กันได้ก่อนว่าเราจะใช้ศัพท์หรือข้อตกลงกันประมาณไหน เช่น
- ID – หมายถึง integer และเป็น unique identifier
- IND – หมายถึง binary
- N – หมายถึง integer ที่เป็นจำนวน
- AMT – หมายถึง numeric ที่เราสามารถหาผลรวมได้
- VAL – หมายถึง numeric เช่นกัน แต่หาผลรวมไม่ได้ เช่น rate หรือ latitude กับ longitude
- DT – หมายถึง date ที่อาจจะมีรูปแบบคือ YYYY-MM-DD
- TM – หมายถึง timestamp
ถ้าเป็นระบบ ride-share อย่าง Uber เราก็อาจจะออกแบบชื่อ column ได้คือ ID_DRIVER, TM_ORIG, VAL_DEST_LONG หรือ IND_TRIP_SURGE เป็นต้น
ซึ่งการตั้งชื่อแบบนี้ก็จะเป็น interface ที่เข้าใจง่ายกับผู้ใช้งาน แล้วก็จะช่วยให้เรา automate งานพวก data management ได้ด้วยเช่นกัน แล้วเรื่อง data quality ก็ทำได้ง่ายขึ้นด้วย อย่างน้อยเราก็รู้ว่า column ไหน หมายถึงอะไร และมี data type ประมาณไหน
ทีนี้ต้องบอกว่า “no silver-bullet” นะ ขึ้นอยู่กับปัจจัยหลาย ๆ อย่างที่เราต้องคำนึงถึงด้วย แต่อย่างน้อยการตั้งชื่อ column ก็เป็นการทำ contract ที่ง่าย และดีวิธีหนึ่งที่เราสามารถเอาไปประยุกต์ใช้งานต่อได้