iKonekt
เปิดคอนโซล

การแยกข้อมูล

เส้นแบ่งที่ฐานข้อมูลเป็นผู้รักษา ไม่ใช่โค้ด

ทุก CRM อ้างว่าตนเองรองรับหลายผู้เช่า การอ้างนั้นราคาถูก สิ่งที่สำคัญคือชั้นไหนเป็นผู้รักษาเส้นแบ่ง ถ้าคำตอบคือ "แอปพลิเคชันของเราใส่ตัวกรองที่ถูกต้องให้เสมอ" แล้วการรับประกันนั้นก็ดีเพียงเท่ากับนักพัฒนาที่พักน้อยที่สุดที่เคยเขียนคิวรีคนหนึ่ง

iKonekt เป็นระบบหลายผู้เช่าตั้งแต่การย้ายข้อมูลครั้งแรก ไม่ใช่มาเสริมทีหลัง ซึ่งฟังดูเหมือนคำโอ้อวด แต่จริง ๆ คือการยอมรับ: การเสริมทีหลังแบบน่าเชื่อถือนั้นเกือบเป็นไปไม่ได้ และทุกคนที่เคยลองมีเรื่องเล่าของตัวเอง

การแยกส่วนอยู่ที่ฐานข้อมูล ทั้งยี่สิบหกตารางทุกตารางระบุผู้เช่าที่ตนสังกัด และนโยบายที่ตรวจสอบเรื่องนี้ทำงานทุกครั้งที่อ่านและทุกครั้งที่เขียน อยู่ต่ำกว่าชั้นแอปพลิเคชันทั้งหมด คิวรีที่ลืมเส้นแบ่งจะไม่คืนข้อมูลลูกค้าของคนอื่น มันคืนค่าว่างเปล่า

ความปลอดภัยระดับแถวข้อมูล บังคับใช้

ไม่ใช่ข้อตกลงร่วมกัน ไม่ใช่กฎของการรีวิวโค้ด ฐานข้อมูลปฏิเสธเอง นโยบายเจ็ดสิบสองข้อ เขียนออกมาทีละข้อ ไม่ใช่สร้างอัตโนมัติ — เพราะนโยบายที่สร้างอัตโนมัติคือนโยบายที่ไม่มีใครอ่าน

คีย์แบบประกอบ

บันทึกลูกอ้างถึงผู้เช่าและบันทึกแม่ของมันพร้อมกัน ในรูปแบบคู่ ตัวระบุที่หลุดมาจากบริษัทอื่นจะไม่ถูกแก้ไข — มันไม่ใช่การอ้างอิงที่ถูกต้องตั้งแต่แรก

ไม่มีผู้เช่าเริ่มต้น ไม่มีวัน

คำขอที่ไม่มีขอบเขตจะไม่เงียบ ๆ กลายเป็นคำขอสำหรับผู้เช่าศูนย์ มันจะส่งข้อผิดพลาดก่อนถึงฐานข้อมูล ไม่มีโหมด "ไม่จำกัดขอบเขต" ให้ลืมปิด

บั๊กที่ประกาศตัวเองไม่ได้

ระหว่างการทำงานเรื่องการแยกผู้เช่า ข้อผิดพลาดส่วนใหญ่เป็นแบบที่ส่งเสียงดัง ลองให้บริษัทสองแห่งใช้โดเมนลูกค้าเดียวกัน ฐานข้อมูลจะส่งวัตถุกลับมาทันทีพร้อมรหัสข้อผิดพลาดและ stack trace ท่านแก้ได้ก่อนพักเที่ยง

มีจุดหนึ่งที่ไม่ได้แสดงปฏิกิริยา ตารางของค่าทับหน้า prompt ที่แก้ไขได้ถูกกำหนดคีย์ด้วยชนิดของ prompt เพียงอย่างเดียว ไม่ใช่ชนิด และ ผู้เช่า บริษัทที่สองที่แก้ไขสำเนาของตนเองจะเขียนทับของบริษัทแรกอย่างเงียบ ๆ ด้วย SQL ที่ถูกต้องสมบูรณ์ ไม่มีข้อผิดพลาด ไม่มีคำเตือน และไม่มีการทดสอบใดล้มเหลว จุดนี้ถูกพบโดยการอ่านดัชนี unique ที่เหลือทั้งหมดทีละรายการหลังจากเปลี่ยนคีย์ เพราะสงสัยว่าตัวที่ส่งเสียงดังคงไม่ได้อยู่ตัวเดียว

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

การทดสอบ ขอบันทึกไว้: ทั้งหมด 942 รายการ รันบนฐานข้อมูลที่สร้างใหม่จากศูนย์ทุกครั้งที่มีการเปลี่ยนแปลง การทดสอบเหล่านี้ไม่ได้อยู่เพื่อพิสูจน์ว่าการออกแบบฉลาด แต่อยู่เพราะรูปแบบความล้มเหลวของการออกแบบแบบนี้เป็นแบบเงียบ และความล้มเหลวแบบเงียบต้องมีใครสักคนตะโกนแทนมัน

การแยกส่วนให้อะไรแก่คนธรรมดา

  • กลุ่มหนึ่งสามารถดำเนินธุรกิจหลายบริษัทจากการติดตั้งชุดเดียว และพนักงานขายของบริษัทหนึ่งจะไม่มีวันเห็นลูกค้าของอีกบริษัท ไม่ใช่ด้วยนโยบาย แต่ด้วยการออกแบบ
  • โปรแกรมพันธมิตร ชุด prompt สิทธิ์เรียกร้องลูกค้า ทั้งหมดถูกกำหนดขอบเขตต่อบริษัท การตั้งค่าของผู้เช่าหนึ่งจึงไม่สามารถกลายเป็นของทุกคนได้
  • คำขอลบข้อมูลจะได้รับการปฏิบัติภายในขอบเขตหนึ่ง ไม่ใช่คร่อมกองข้อมูลที่ใช้ร่วมกัน ซึ่งเป็นสิ่งที่ทำให้สามารถตอบอย่างสุจริตได้
  • และไม่มีใครต้องจดจำเรื่องนี้เลย นั่นคือประเด็น หลักประกันที่ต้องอาศัยการจดจำไม่ใช่หลักประกัน

อีกหนึ่งบรรทัดที่ไม่ได้พูดถึงฐานข้อมูล

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

มันคือสัญชาตญาณเดียวกับกฎของฐานข้อมูล ทำให้สิ่งที่ผิดเป็นไปไม่ได้แทนที่จะเป็นเพียงการไม่สนับสนุน แล้วท่านจะใช้ความสนใจไปกับลูกค้าแทนที่จะใช้ไปกับการเฝ้าระวัง

ขอบเขตใต้ชั้นแอปพลิเคชัน
  • 126 ตารางทุกตารางมีข้อมูลผู้เช่าของตน โดยบังคับใช้เช็กไว้
  • 272 นโยบายเขียนออกมาทีละรายการ จึงมีคนอ่านแล้วทุกฉบับ
  • 3942 การทดสอบบนฐานข้อมูลที่สร้างใหม่จากศูนย์ ทุกครั้งที่มีการเปลี่ยนแปลง
  • 40 ผู้เช่าเริ่มต้นคำขอที่ไม่มีขอบเขตจะไม่มีวันไปถึงข้อมูล

วัดจากบิลด์ที่ใช้งานจริง

“แอปพลิเคชันของเรากรองตามบริษัทเสมอ”

คำว่าเสมอในประโยคนั้นทำงานหนักอยู่ไม่น้อย

ย้ายขอบเขตลงไปในฐานข้อมูล แล้ว WHERE clause ที่ถูกลืมจะคืนค่าว่างแทนที่จะเป็นลูกค้าของคนอื่น หน้าจอว่างเปล่าเป็นความล้มเหลวที่ดีกว่าการแนะนำตัวอย่างอึดอัด

สำหรับกลุ่มที่ดำเนินธุรกิจหลายแบรนด์ →