คำสั่ง SQL ทุกคำสั่งจะต้องได้รับการตรวจสอบโดย DBA

11

ฉันหมายถึงทุกสิ่งไม่ใช่แค่การเปลี่ยนแปลงคีมา แม้แต่ SELECT อย่างง่ายบนคีย์หลักก็ไม่สามารถทำการผลิตได้แม้ว่ามันจะได้รับการตรวจสอบโค้ดโดยผู้พัฒนาคนอื่น ๆ (ในบริบท) โดยไม่มีการตรวจสอบ DBA ของทุกคำสั่งสกัดจากโค้ดและส่งด้วย EXPLAIN รายละเอียด ความถี่ที่จะถูกเรียก ฯลฯ และอื่น ๆ

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

code-reviews dba

— Isvara
แหล่งที่มา

2

เราไม่ใส่คำสั่ง SQL ลงในโค้ด อย่างไรก็ตามรหัสทั้งหมดควรได้รับการตรวจสอบโดยผู้มีความรู้ที่เหมาะสม

— CaffGeek

4

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

— thiton

2

คำถามคือถ้าไม่ใช่ทุกคำถามจะถูกส่งผ่านโดย DBA คุณจะกำหนดสิ่งที่ควรและไม่ควรผ่านโดย DBA อย่างไร

— โปรแกรมเมอร์

6

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

— FrustratedWithFormsDesigner

2

คุณยังไม่ถูกกัดเหรอ? ลองถามว่าเหตุใดจึงมีกระบวนการนี้ ...

15

ที่หนึ่งในงานก่อนหน้าของฉันฉัน (พร้อมกับโปรแกรมเมอร์อีกสามคน) มีหน้าที่รับผิดชอบในการตรวจสอบทุกขั้นตอนการจัดเก็บที่สร้างขึ้นหรือปรับปรุงก่อนที่มันจะเข้าสู่การผลิตสำหรับโปรแกรมเมอร์ประมาณ 40+ ในฐานะผู้ตรวจสอบมันเป็นการลากที่แท้จริงในเวลาของฉัน แต่โดยรวมแล้วมันก็ยังต้องการเพราะนักพัฒนาหลายคนจะทำผิดพลาดเป็นครั้งคราว มันเกิดขึ้นเพราะเรามีโปรแกรมเมอร์นอกชายฝั่งที่เขียนคำสั่ง SQL ที่ไม่ดี (มีประสิทธิภาพ) และพวกเขาก็ปฏิเสธที่จะเรียนรู้ (ในที่สุดทีมก็ปิดตัวลง)

โดยรวมแล้วเรามองหา:

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

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

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

อัปเดต ในงานแรกของฉันคำค้นหาทั้งหมดเขียนโดย DBA และนั่นเป็นช่วงเวลาสำคัญในการพัฒนา ฉันต้องส่งคอลัมน์ทั้งหมดที่ฉันต้องการตารางที่คอลัมน์ตั้งอยู่และในที่สุดเกณฑ์การค้นหาของฉัน แม้แต่คำสั่ง insert / update / delete พื้นฐานที่จำเป็นในการผ่าน DBA ในที่สุดฉันก็มาถึงจุดที่ฉันสามารถเขียน SQL ที่ฉันต้องการได้ให้พวกเขาดูและทำการเปลี่ยนแปลงที่จำเป็นแล้วห่อกระบวนงานที่เก็บไว้รอบ ๆ แต่นั่นมีเพียงไม่กี่ปีที่นั่น บริษัท นั้นจ้างบัณฑิตวิทยาลัยจำนวนมากเมื่อไม่นานมานี้และนี่คือวิธีที่ทำให้พวกเขามั่นใจว่าคนใหม่ไม่ได้เขียนข้อความค้นหาที่ฆ่าประสิทธิภาพ

— bwalk2895
แหล่งที่มา

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

— Michael Durrant

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

— Isvara

1

มีเครื่องมือใดที่จะทำให้สิ่งนี้เป็นแบบอัตโนมัติหรือไม่? ฉันกำลังคิดของเครื่องมือที่สร้างแผนการดำเนินการสำหรับการค้นหาที่ส่งทั้งหมดแล้วทำเครื่องหมายสิ่งใดด้วยการสแกนแบบเต็มตารางหรือผลิตภัณฑ์คาร์ทีเซียน ฉันสงสัยว่ามันสามารถจับทุกอย่างได้ แต่มันอาจเร็วขึ้นในการตรวจสอบเวลาและมันก็สามารถทำงานได้โดยนักพัฒนาผ่านสคริปต์หรือดียิ่งขึ้นถ้าทำงานโดยอัตโนมัติในเวลาเช็คอินโค้ด

— FrustratedWithFormsDesigner

10

ทั้งหมดขึ้นอยู่กับสภาพแวดล้อมอุตสาหกรรมและ บริษัท

ตัวอย่างบางส่วน:

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

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

— Michael Durrant
แหล่งที่มา

5

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

นักพัฒนาใช้เวลาในการดึง sql ออกจากรหัสและใช้เวลาเตรียมที่จะส่งไปยัง DBA
DBA ใช้เวลานานเท่าใดในการตรวจสอบ sql
DBA ร้องขอการเปลี่ยนแปลงบ่อยเพียงใด แยกตาม
ประเภทข้อความค้นหา

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

— BZink
แหล่งที่มา

6

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

4

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

— BZink

4

นักพัฒนาส่วนใหญ่จะไม่สนใจเกี่ยวกับฐานข้อมูล พวกเขาไม่ได้ตระหนักถึงความไม่รู้ของพวกเขา ฉันเคยเป็นนักพัฒนาที่ไม่รู้ตัวเอง

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

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

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

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

— FormerIgnorantDeveloper
แหล่งที่มา

คุณต้องการที่จะฟังเสียงที่มีความศักดิ์สิทธิ์กว่าท่านอีกหรือไม่?

— sevenseacat

2

@Karpie อย่างน้อยเขาก็ใช้เวลาในการตอบสนองต่อภาพวาดจากประสบการณ์ของเขาเองมากกว่าที่จะแสดงความคิดเห็นที่ไร้ค่าและเสียดสีต่อคำตอบของคนอื่นอย่างคาร์ปี

— ดึง

2

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

— TMN
แหล่งที่มา

2

ฉันไม่ได้ทำงานในสภาพแวดล้อมเช่นนี้และฉันก็จะไม่

มีความแตกต่างระหว่างการทำงานเป็นทีมและระบบราชการที่ไม่เป็นมิตร ในฐานะนักพัฒนาฉันชอบที่จะมี DBA สำหรับการสืบค้นที่ยาก แต่ฉันรู้ว่าเมื่อไหร่จะขอความช่วยเหลือ

หากฉันไม่เก่งพอสำหรับSELECTคำค้นหาง่าย ๆฉันควรถูกไล่ออก

— นาธานลอง
แหล่งที่มา

1

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

— Murph

2

@Murph - อย่างแน่นอน ฉันทำผิดพลาดได้ แต่ฉันสามารถใช้เวลาอาบน้ำ 2 ชั่วโมงทุกวัน ทุกคนควรจะต้องติดตามเวลาเข้าห้องน้ำเพื่อป้องกันไม่ให้? เราควรจะต้องลงชื่อในแบบฟอร์มเพื่อรับคลิปหนีบกระดาษเพื่อหลีกเลี่ยงการขโมยคลิปหนีบกระดาษหรือไม่? ในบางจุดคุณต้องเชื่อใจผู้คนหรือไล่พวกเขาออก ข้อความค้นหาที่ช้าของฉันมีค่าใช้จ่าย แต่กระบวนการตรวจสอบที่น่าดึงดูดและใช้เวลานาน เฉพาะในกรณีที่ความแตกต่างของประสิทธิภาพของฐานข้อมูลขนาดเล็กจะมีค่าใช้จ่ายหลายล้าน (หรือชีวิต) ฉันจะยอมรับสิ่งนี้

— นาธานลอง

1

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

— Telastyn

@Telastyn - "ไม่ใช่นักพัฒนาโดยเฉลี่ย" ฉันไม่ซื้อ ฉันยังบอกว่าอย่าจ้างนักพัฒนาที่ไม่ดี แต่ใช่ถ้า DBA จำเป็นต้องรับสายฉันก็เห็นใจมากขึ้น

— นาธานลอง

@NathanLong เกี่ยวกับบริบท - ในบริบทที่คุณทำงานอย่างไม่เป็นปัญหาในที่อื่น ๆ ชัดเจนว่ามันมีศักยภาพที่จะเป็นและหนึ่งในวิธีที่คุณหลีกเลี่ยงปัญหาบางอย่างคือการมีสิ่งที่ดูเหมือนจะเป็นกฎที่ไม่สนใจ (แม้ว่า เช่นเดียวกับความจริงที่ว่าผมมักจะใช้ {} หากงบของฉันมันทำเพื่อวัตถุประสงค์) มันแย่ "เพราะฉันไม่ชอบและฉันคิดว่าฉันปลอดภัยดังนั้นมันจึงไม่ควรใช้กับฉัน" เป็นข้อโต้แย้งที่น่าสงสัย (ตรรกะเดียวกันนี้ใช้กับการเพิกเฉยต่อการ จำกัด ความเร็ว) อืมนั่นเป็นเหตุผล) -: ขออภัย

— Murph

2

ฉันเคยเห็นสิ่งนี้ทำในสถานที่ที่แตกต่างกันสองแห่ง มันยอดเยี่ยมในทางทฤษฎี แต่ฉันไม่ค่อยเห็นว่าจะมีประสิทธิภาพ นี่คือเหตุผล ประการแรกหากคุณมีทีมงาน DBA (หรือคนอื่น ๆ ) ฉันพบโดยทั่วไปว่าบุคคลที่มีความสามารถหรือชอบน้อยที่สุดในกลุ่มจะได้รับผลงานรีวิวที่หนักหน่วง ทำไมคุณถึงพูด? เป็นเพราะไม่มีใครอยากทำและทุกคนไม่ว่างทำสิ่งอื่นที่อาจเร่งด่วนกว่า เคยเห็น DBA นั่งรอแล้วพูดว่า "มนุษย์ทุกอย่างทำงานได้อย่างสมบูรณ์แบบฉันสามารถนั่งเอนหลังเล่นเน็ตได้ อย่างน้อยฉันก็ไม่ใช่คนดี พวกเขายุ่งหรือยุ่งกว่าคนอื่น ซึ่งหมายความว่าบุคคลที่มีความสามารถน้อยที่สุดน่าจะเป็นผู้ทำการตรวจทานและนี่คือบุคคลที่คุณไม่ต้องการทำ รหัสที่คุณต้องการตรวจสอบคือรหัสที่ยากมาก ๆ ที่ผู้คนมองและส่งมันออกมาเป็นเวทมนตร์สีดำ จูเนียร์ DBA หรือเพียงแค่คนเลวธรรมดาจะไม่สามารถจับรายละเอียดปลีกย่อยของการทำงานของการสืบค้นที่ยาก บางคนไม่เคยพูดว่า "ฉันไม่คิดว่าจะเลือกแถวเดียวออกจากตารางโดยใช้คีย์หลัก! ขอบคุณ DBA ที่คุณเป็นผู้ช่วยชีวิต" ดังนั้นในสถานการณ์นี้สิ่งที่คุณกำลังทำจริงๆคือการสร้างงานจำนวนมากโดยมีมูลค่าเพียงเล็กน้อย อย่าคิดว่าจะเลือกแถวเดียวออกจากตารางโดยใช้คีย์หลัก! ขอบคุณ DBA คุณเป็นผู้ช่วยชีวิต "ดังนั้นในสถานการณ์สมมตินี้สิ่งที่คุณทำจริงๆคือการสร้างงานจำนวนมากด้วยค่าเพียงเล็กน้อย อย่าคิดว่าจะเลือกแถวเดียวออกจากตารางโดยใช้คีย์หลัก! ขอบคุณ DBA คุณเป็นผู้ช่วยชีวิต "ดังนั้นในสถานการณ์สมมตินี้สิ่งที่คุณทำจริงๆคือการสร้างงานจำนวนมากด้วยค่าเพียงเล็กน้อย

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

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

— kemiller2002
แหล่งที่มา

2

ฉันทำงานในสภาพแวดล้อมแบบนั้น การเปลี่ยนแปลงระบบทั้งหมดได้รับการตรวจสอบโดยเพื่อนที่เหมาะสม สำหรับฉันมันหมายถึงฉันต้องวางแผนล่วงหน้าและส่งการเปลี่ยนแปลงของฉันล่วงหน้าสองสามวัน SQL ไปที่ DBA ซึ่งท้ายที่สุดจะปล่อย SQL ลงในการผลิต

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

— เอียน
แหล่งที่มา

0

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

นักพัฒนาที่ไม่มีประสบการณ์อาจลากฐานข้อมูลลงไปที่หัวเข่าด้วยการใช้ ORM ในทางที่ผิดหรือการสืบค้นที่อยู่ไกลจากที่ดีที่สุด

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

— Andrzej Bobak
แหล่งที่มา

0

ในทีมพัฒนาของเรามีทีมย่อยของนักพัฒนาฐานข้อมูล 4 คนที่มีประสบการณ์ในแพลตฟอร์ม DBMS ที่เราใช้ พวกเขาเขียน SQL ทั้งหมดหรือทบทวนอย่างน้อยที่สุดและทำการเปลี่ยนแปลงเพื่อให้เป็นไปตามมาตรฐานการเข้ารหัส SQL ใด ๆ ที่เขียนโดยนักพัฒนา. Net พวกเขาเป็นส่วนหนึ่งของทีมงานโครงการ DBA การผลิตเป็นของแผนกที่แตกต่างกันโดยสิ้นเชิงและงานของพวกเขาคือการดำเนินงาน พวกเขาไม่ได้ตรวจสอบรหัส SQL หรือสคีมาของเราและแม้แต่การปรับใช้ก็ยังถูกสคริปต์ทั้งหมดที่พวกเขาทำก็คือเรียกใช้สคริปต์ สิ่งที่พวกเขาช่วยได้มากที่สุดคือการปรับแต่งประสิทธิภาพ

— softveda
แหล่งที่มา