ฉันควรอัปเดตอย่างชัดเจนไปยังคอลัมน์ที่ไม่ควรอัปเดตหรือไม่

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

ตัวอย่างเช่น:

create table dbo.something (
    created_by varchar(50) not null,
    created_on datetimeoffset not null
);

คอลัมน์สองเหล่านี้ไม่ควรเปลี่ยนแปลงเมื่อมีการตั้งค่า ดังนั้นผมจะชัดเจนรับอนุญาตเกี่ยวกับพวกเขาDENYUPDATE

เมื่อเร็ว ๆ นี้ในระหว่างการประชุมทีมนักพัฒนาได้ยกประเด็นที่ตรรกะเพื่อให้แน่ใจว่าเขตข้อมูลที่ไม่เคยได้รับการปรับปรุงควรจะอยู่ในเลเยอร์แอปพลิเคชันและไม่ใช่ชั้นฐานข้อมูลในกรณีที่ "พวกเขาจำเป็นต้องปรับปรุงค่า สำหรับฉันแล้วดูเหมือนว่าความคิด dev ทั่วไป (ฉันรู้ว่าฉันเคยเป็นหนึ่ง!)

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

แนวปฏิบัติที่ดีที่สุดในสถานการณ์นี้คืออะไร?

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

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

ฉันเห็นด้วยอย่างยิ่งกับ @Aaron ในด้านเทคนิคของสิ่งนี้

นอกเหนือจากที่ฉันจะพูดเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุด:

1. ระบุว่าเป็นหน้าที่ / ความรับผิดชอบของ DBA ในการปกป้องข้อมูลวิธีการเริ่มต้นควรทำเช่นนั้นตามที่ DBA เห็นว่าเหมาะสมและต้องการกรณีศึกษาทางธุรกิจที่แข็งสำหรับการเปลี่ยนแปลง สมมติฐานในอนาคตที่มีศักยภาพค่อนข้างเป็นไปได้ที่กำหนดเงื่อนไขบางอย่างที่จะได้รับการระดมสมองในภายหลังและยืนยันว่าเป็นอย่างดีหลังจากนั้น แต่อาจจะเปลี่ยนในภายหลังหรืออาจจะไม่เคย - จริง - เกิดขึ้นเหตุผล (เช่น "ด้วยเหตุผลบางอย่าง") ดูเหมือนว่ามีเหตุผลเล็กน้อยโดยเฉพาะเมื่อหัวข้อเปลี่ยนมาตรฐาน / การปฏิบัติของ บริษัท

2. อย่าไว้ใจใครสักคนที่ต้องการเปลี่ยนแปลงสิ่งที่ไม่ควรเปลี่ยนแปลง ;-) (ยิ่งกว่านั้นหากพวกเขาไม่รู้ด้วยซ้ำว่าทำไมพวกเขาถึงต้องการ)

3. บอกผู้พัฒนาว่าพวกเขายินดีที่จะเพิ่มตรรกะดังกล่าวลงในรหัสแอปเพื่อป้องกันการอัปเดตเหล่านั้น DENYแต่ยังว่าคุณจะไม่ได้ไปเอา หาก / เมื่อวันนั้นมาถึง (และมันอาจจะไม่อาจจะไม่) ที่ใครบางคนได้รับข้อผิดพลาดในการพยายามอัปเดตหนึ่งในคอลัมน์เหล่านี้จากนั้นคุณสามารถมีการอภิปรายเกี่ยวกับว่าคุณจะลบหรือไม่DENYซึ่งจะต้องมีเหตุผลที่แท้จริงและมั่นคง ที่แรก.

   ประเด็นที่ควรพิจารณา: ควรมีกรณีธุรกิจจริง ๆ ที่ขับเคลื่อนสิ่งที่ผู้คนใช้เวลา เวลามีความต้องการสูง แต่มีข้อ จำกัด ดังนั้นคุณ (และคนอื่น ๆ ) จึงมีสิ่งที่สำคัญกว่าที่จะทำมากกว่าเปลี่ยนระบบตามความเห็นของใครบางคน จะมีความคิดเห็นที่หลากหลาย (ช่องว่าง vs แท็บทุกคนหรือไม่) และคุณสามารถใช้เวลาหลายปีในการเปลี่ยนแปลงสิ่งนี้ไปมาถ้านักพัฒนาคนนั้นออกไปและถูกแทนที่ด้วยผู้ที่คัดค้านอย่างยิ่งต่อฟิลด์เหล่านั้น หากไม่มีลูกค้าขอสิ่งนี้ (หรือสิ่งที่ต้องการ) และไม่มีประโยชน์ที่จับต้องได้ (แม้จะล่าช้ากว่าผลประโยชน์เช่นการล้างหนี้ทางเทคนิคซึ่งเป็นการยากที่จะแสดงผลตอบแทนจากการลงทุน แต่มีค่ามากในขณะที่ โอกาสของการใช้เวลาที่ไม่ส่งผลในการประหยัดต้นทุนจริงในระยะยาวจะผอมไปไม่มี) จากนั้นปิดคำขอหรือวางไว้บน backlog ที่ระดับความสำคัญต่ำแม้ในกรณีที่อุดมคตินิยมบอกว่าควรเปลี่ยน (นี่ไม่ใช่หนึ่งในกรณีเหล่านั้น แต่กล่าวถึงสำหรับคนที่คิดว่ามันเป็น) ความเพ้อฝันเป็นสิ่งที่ดีสำหรับการสนทนา แต่ บริษัท ไม่สามารถจ่ายค่าเช่าค่าสาธารณูปโภคพนักงานภาษีและอื่น ๆ ด้วยอุดมคติ

4. @ jpmc26 ถูกต้องเกี่ยวกับความต้องการในการสื่อสาร แต่ไม่ถูกต้องอย่างแน่นอนเกี่ยวกับสิ่งที่ต้องมีการสื่อสาร ใช่คุณควรฟังสิ่งที่คนอื่นร้องขอและพยายามเข้าใจเหตุผลของพวกเขาซึ่งรวมถึงการถามคำถามหากคุณไม่ชัดเจนเกี่ยวกับอะไร

   อย่างไรก็ตามฐานข้อมูลจะไม่ยอมให้แอปพลิเคชันและผู้เชี่ยวชาญด้านฐานข้อมูล (ผู้ดูแลระบบวิศวกรชื่อใดก็ตามที่ บริษัท ของคุณใช้) จะไม่ยอมให้นักพัฒนาซอฟต์แวร์ (ตามที่ดูเหมือนจะบอกเป็นนัยในคำตอบนั้น) คุณไม่ได้ทำงานให้กับนักพัฒนา แต่ทำงานให้กับ บริษัท เช่นเดียวกับพวกเขา นี่เป็นความพยายามของทีมและคุณไม่ควรให้อภัยในการทำงานของคุณ ที่กล่าวว่าคอมพิวเตอร์ของเราไม่เป็นที่รู้จักในด้านทักษะการสื่อสารระหว่างมนุษย์ดังนั้นคุณต้องให้แน่ใจว่าคนอื่นเข้าใจคุณสิ่งที่เหตุผลของคุณคืออะไรความรับผิดชอบของคุณคืออะไรและสิ่งนี้ทำงานอย่างไร .

   ฉันใส่ในส่วนสุดท้ายนั้นเพราะมีความเข้าใจผิดระดับสูงข้อมูลที่ผิดและการขาดความรู้ออกไป (แม้แต่บางส่วนที่นี่ในหน้านี้) ตัวอย่างเช่นดูเหมือนว่ามีความคิดนี้ว่ากฎทั้งหมดเป็นกฎทางธุรกิจ เราจำเป็นต้องอธิบายว่ามีความแตกต่างระหว่างกฎข้อมูลและกฎเกณฑ์ทางธุรกิจ (@Aaron เรียกสิ่งนี้ว่า "ข้อ จำกัด เวิร์กโฟลว์เทียบกับข้อ จำกัด ของข้อมูล" ในความคิดเห็นเกี่ยวกับคำถาม) และในขณะที่ข้อมูลส่วนใหญ่เป็นของแอปพลิเคชัน อันที่จริงเป็นของตัวแบบข้อมูล DBA ควรบอกผู้พัฒนาว่าข้อมูลแอปพลิเคชันจะถูก จำกัด อย่างไร ไม่แน่นอน เป็นหน้าที่ของเราที่จะเสนอวิธีการที่ข้อมูลแอปพลิเคชันสามารถทำได้ถูกบังคับ หากการละเมิดกฎธุรกิจที่เกี่ยวข้องกับข้อมูลแอปพลิเคชันอาจก่อให้เกิดอันตรายและแอปไม่ใช่วิธีเดียวที่จะจัดการข้อมูลได้100%ดังนั้นข้อ จำกัด การตรวจสอบอาจช่วยได้จริงๆ (และพวกเขาก็ไม่ยากที่จะเปลี่ยนหรือลบ )

   แต่มาจากทิศทางอื่นนักพัฒนาไม่ควรกำหนดวิธีจัดการข้อมูลตัวแบบข้อมูล (เช่น meta-data) ซึ่งรวมถึงฟิลด์การตรวจสอบ (เช่นcreated_on/ created_byคอลัมน์) และคอลัมน์ PK / FK (ค่าเหล่านี้ควรจะเป็นที่รู้จักเท่านั้นภายในและไม่ได้มอบให้กับลูกค้า) ข้อมูลนี้ไม่ใช่สิ่งที่แอพเก็บเกี่ยวกับลูกค้า (แม้ว่าแอปจะสามารถดูค่าและใช้งานได้เช่นด้วย ID) แต่เป็นข้อมูลโมเดลที่เก็บข้อมูลเกี่ยวกับข้อมูลของแอพ

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

ดังนั้น:

1. ใช่ฉันชอบความคิดที่ชัดเจนDENYเกี่ยวกับคอลัมน์การตรวจสอบและได้เสนอเหมือนกันในสถานที่ที่ฉันเคยทำงานในอดีตเช่นกัน

2. โดยทั่วไปฉันมีการสนทนาที่คล้ายกันมากกับผู้พัฒนานำ (ดีมาก) อาจเป็นในปี 2000 เมื่อฉันเริ่มเพิ่มคีย์ต่างประเทศ เขาแย้ง (ค่อนข้างจริงจัง) ว่ามันไม่จำเป็นกับวิศวกรรม / อุดมคตินิยม (บางอย่างเช่นนั้นมันเป็นเวลา 17 ปีนับตั้งแต่การสนทนาครั้งนั้น) และไม่คุ้มค่ากับผลงานยอดเยี่ยม เขาค่อนข้างชัดเจนว่าควรล้างข้อมูลที่เกี่ยวข้องในเลเยอร์แอพ (ใช่ฉันเพิ่ม FKs เพราะเขาจะไม่เป็นคนหนึ่งในการทำความสะอาดข้อมูลเด็กกำพร้าที่รหัสของเขาจะสร้างอย่างหลีกเลี่ยงไม่ได้)

   หลายปีต่อมาเขาขอโทษที่ทำเรื่องนั้น ;-)

นี่อาจเป็นปัญหา XY created_onนักพัฒนาอาจจะไม่ได้เกี่ยวข้องเฉพาะอย่างยิ่งกับการปิดกั้นการปรับปรุงสนามอย่างต่อเนื่องอย่างแท้จริงเช่น ตัวอย่างนี้โดยเฉพาะอย่างยิ่งเป็นมากจำกัด เจียมเนื้อเจียมตัว

นักพัฒนาอาจกังวลว่าทีม DBA (ซึ่งรวมถึงคุณ) มุ่งมั่นที่จะเพิ่มข้อ จำกัด ที่ซับซ้อนมากหรืออย่างนั้นซึ่งมันเริ่มเป็นอุปสรรคต่อความสามารถในการทำงานได้อย่างมีประสิทธิภาพหรือเมื่อสิ่งที่ผิดปกติเกิดขึ้นหรือการเปลี่ยนแปลงบางอย่างทีม DBA จะต่อต้านการเปลี่ยนแปลงและขัดขวางความสามารถของทีมนักพัฒนาในการสร้างความก้าวหน้า นี่เป็นข้อกังวลที่สมเหตุสมผล ระบบราชการและการสูญเสียความสามารถในการทำให้เกิดการเปลี่ยนแปลงที่จำเป็นนั้นเกิดขึ้นจริงและการเข้ารหัสข้อ จำกัด ที่ซับซ้อนหรือมากเกินไปอาจส่งผลเสียต่อประสิทธิภาพและความสามารถในการตอบสนองต่อการเปลี่ยนแปลงข้อกำหนด

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

ดังนั้นมีสองสามสิ่งที่คุณควรทำเพื่อระงับความกลัวเหล่านี้:

1. สื่อสารอย่างหนักแน่นกับผู้พัฒนา ตรวจสอบให้แน่ใจว่าคุณเข้าใจความต้องการของฟีเจอร์ที่พวกเขากำลังพยายามสร้างและแน่ใจว่าคุณตอบสนองได้เมื่อมีการเปลี่ยนแปลงเกิดขึ้น ฟังสิ่งที่พวกเขาพูดและทำงานอย่างหนักเพื่อหาวิธีแก้ไขปัญหาที่สร้างความกังวลให้กับคุณ เต็มใจที่จะงอเมื่อพวกเขามีความต้องการที่ถูกกฎหมาย ตรวจสอบให้แน่ใจว่าพวกเขารู้ว่าคุณเป็นพันธมิตรในการสร้างซอฟต์แวร์
2. ระมัดระวังเกี่ยวกับการ จำกัด ข้อ จำกัด แม้กระทั่งการให้ความสมบูรณ์และความปลอดภัยก็สามารถปรับตัวให้เข้ากับการเปลี่ยนแปลงหรือรับมือกับสถานการณ์ที่ไม่คาดฝันได้ยากขึ้น ดังนั้นเข้าใจว่าข้อ จำกัด แต่ละข้อที่คุณเพิ่มนั้นมีแนวโน้มว่าจะมีค่าใช้จ่ายที่เกี่ยวข้องเนื่องจากมันมีแนวโน้มที่จะประหยัดค่าใช้จ่าย (ยกเว้นข้อยกเว้นที่เป็นไปได้ของคีย์หลักและคีย์ต่างประเทศซึ่งไม่มีข้อเสีย) มั่นใจได้ว่าข้อ จำกัด ที่คุณกำหนดนั้นจำเป็นจริงๆหรือเป็นประโยชน์
3. ฉันไม่เห็นสัญญาณใด ๆ ที่คุณทำ แต่ฉันต้องการพูดถึงมันสำหรับผู้อ่านอื่น ๆ : อย่าดูข้อมูลหรือฐานข้อมูลเป็นความรับผิดชอบของคุณหรือทีมของคุณ ข้อมูลเป็นสินทรัพย์ของทั้ง บริษัท หากไม่มีระบบในการจัดเก็บ (ฐานข้อมูล) และสคริปต์เครื่องมือหรือแอปพลิเคชันเพื่อสร้างอัปเดตและดึงข้อมูลข้อมูลนั้นไร้ค่า เนื่องจากทุกคนต้องใช้เนื้อหานี้ข้อมูลจึงเป็นความรับผิดชอบของทุกคน ฐานข้อมูลเองเป็นเพียงส่วนหนึ่งในการรับค่าจากข้อมูล

คุณมีข้อความที่ขัดแย้งกัน

• คอลัมน์ที่ไม่ควรอัปเดต
• พวกเขาจำเป็นต้องปรับปรุงค่าด้วยเหตุผลบางอย่าง

มันขึ้นอยู่กับคุณแล้วที่จะกำหนดคนแรก?

คุณมีสิทธิ์อย่างน้อยที่สุดในการทำให้แอปทำงานโดยไม่มีข้อพิสูจน์แอพจะไม่จำเป็นต้องอัปเดตค่า

ใครรับผิดชอบความถูกต้องของข้อมูล

ด้วยข้อ จำกัด ของ SQL คุณสามารถรับประกันความถูกต้องของข้อมูลได้หรือไม่ ไม่คุณไม่สามารถทำได้เนื่องจากมักมีกฎเกณฑ์ทางธุรกิจที่นอกเหนือไปจากที่ฐานข้อมูลสามารถทำได้

VendorID ไม่ควรเปลี่ยนแปลง แต่จะเกิดอะไรขึ้นถ้าผู้ขายสองรายรวมกัน ไม่เคยพูดไม่เคย

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

คำถามที่เหมาะสมคือหากแอพอัปเดตข้อมูล