มันสมเหตุสมผลหรือไม่ที่จะสร้างมาตรฐานรวมถึงวันที่สร้างและวันที่อัปเดตล่าสุดในตารางฐานข้อมูลทั้งหมด


37

เจ้านายของฉันกำลังพยายามใช้มาตรฐานการพัฒนาบางอย่างกับทีมของเราดังนั้นเราจึงมีการประชุมเมื่อวานนี้เพื่อหารือเกี่ยวกับมาตรฐานซึ่งส่วนใหญ่จะเป็นไปด้วยดีจนกระทั่งเธอโตขึ้น:

  • ตาราง DB ทั้งหมดจะมีคอลัมน์ CreatedDate และ LastUpdatedDate ซึ่งอัพเดตโดยทริกเกอร์

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

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

ดังนั้นคำถามของฉันคือสองเท่า:

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

ทำไมคุณถึงบอกว่า C # ไม่มีความสุขกับคำสั่ง นอกจากนี้การเพิ่มคุณสมบัติ [insert = "false" update = "false" created = "always"] ในการแมปของคอลัมน์ทั้งสองใน NHibernate เช่นนั้นดูเหมือนจะไม่แปลกใจสำหรับฉันหรือฉันขาดอะไรบางอย่าง?
Jalayn

C # + Oracleไม่มีความยินดีในการใช้ ORM และเราพบว่า NHibernate นั้นมีน้ำหนักมากเกินไป (เห็นได้ชัดว่าฉันไม่ได้มีส่วนร่วมในการตรวจสอบเครื่องมือแบบนั้น) ฉันอาจวาง C # และ Oracle ไว้ในคำถามหลัก
Ed James

คุณควรพิจารณาเปลี่ยนชื่อหัวข้อคำถามของคุณเพื่ออธิบายมาตรฐานฐานข้อมูลให้มากขึ้น
maple_shaft

สิ่งนี้จะใช้เวลาห่างจากอะไร คุณจะต้องทำอย่างน้อยสองครั้งสำหรับ 'คดีภายนอก' สร้างเครื่องมือและคลาสที่สามารถใช้ซ้ำได้และไม่ต้องกังวลอีกต่อไป
Steven Evers

คำตอบ:


27

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

หากคุณกำลังจัดการกับข้อมูลทางการเงินหรือข้อมูลที่กระตุ้นความรู้สึกใด ๆ ฉันมั่นใจว่าคุณได้ยินสิ่งต่าง ๆ เช่นการปฏิบัติตามมาตรฐานPCIและSOX การมีหลักฐานการตรวจสอบที่ครอบคลุมเป็นสิ่งจำเป็นในการปฏิบัติตามข้อกำหนดเหล่านั้น ..

คำเตือน: อย่างไรก็ตามยังมีวิธีที่ดีกว่ามากในการบรรลุเส้นทางการตรวจสอบฐานข้อมูล> https://stackoverflow.com/questions/1051449/ideas-on-database-design-for-capturing-audit-trails


ขออภัยลืมที่จะพูดถึงไม่เป็นไปตามมาตรฐาน PCI (ฯลฯ ) มีกระบวนการติดตามตรวจสอบในบันทึกอยู่แล้ว (บันทึกทุกอย่างค่อนข้างละเอียด)
Ed James

6
"(บันทึกทุกอย่างค่อนข้างชัดเจน)"มีการสร้างวันที่และวันที่อัปเดตครั้งสุดท้ายหรือไม่ ถ้าเป็นเช่นนั้นคุณอาจจะสามารถชี้ให้เพื่อนร่วมงานของคุณต่อหลักการแห้ง :)
MattDavey

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

3
ฉันไม่คิดว่าวิธีการนี้จะทำให้ได้หลักฐานการตรวจสอบที่หลากหลาย ... ฉันจะไม่เรียกมันว่าเป็นหลักฐานการตรวจสอบเลย
Jordão

@ Jordãoฉันบอกว่ามันเป็นวิธีการทั่วไปฉันไม่ได้บอกว่ามันเป็นวิธีที่ดี! ดังนั้นข้อจำกัดความรับผิดชอบ :)
MattDavey

16

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

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

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


8
สร้างสคริปต์ที่จะเพิ่มคอลัมน์เหล่านี้ลงในทุกตารางหากไม่มีอยู่พร้อมกับทริกเกอร์
JeffO

3
+1 คุณสามารถสร้างรหัสสคริปต์ได้อย่างง่ายดายในไม่กี่วัน ทำงานมากเท่านั้นถ้าทำด้วยตนเอง
Jon Raynor

8

... คำแถลงที่ชัดเจนยิ่งขึ้นที่มนุษย์ทำให้เขามีแนวโน้มที่จะผิดอย่างแน่นอน ... - tyler durden

สิ่งนี้นำไปใช้กับ "มาตรฐาน" แบบครอบคลุมในขณะที่บนโต๊ะบางตัวอาจเป็นชัยชนะครั้งใหญ่ในทุก ๆตารางมันน่าจะเป็นเสียงที่ไร้ประโยชน์และรหัสอื่น ๆ ที่จะรักษาหรือลืมที่จะรักษา

มีความสมดุลที่จะมีที่นี่นั่นคือสิ่งที่คุณควรผลักดันให้ผู้มีอำนาจตัดสินใจ


8

ฉันเห็นด้วยสุดใจ เกือบตารางในฐานข้อมูลทุกทุกคนควรมีอย่างน้อย 2 สาขาที่: วันที่สร้างและวันที่อัพเดต มีสาเหตุหลายประการที่คุณควรใส่วันที่สร้างและวันที่อัปเดต ด้วยเหตุผลที่ชัดเจนว่าคนก่อนระบุ ... ซึ่งเป็นการตรวจสอบ

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

มีวิธีพื้นฐาน 2 ประการดังนี้:

1 - วิธีปฏิบัติแรกคือให้ฐานข้อมูลทำงานและวางลงในการออกแบบตารางโดยตรง ซึ่งเป็นขั้นต่ำเปล่าฉันอยากจะแนะนำ

2 - แนวปฏิบัติอื่น ๆ ที่ฉันชอบ .... ใช้เครื่องมือจำลองแบบเพื่อจัดการสิ่งนี้ มีค่าใช้จ่ายเล็กน้อยและไม่มีค่าใช้จ่ายสำหรับทีม DEV อย่างไรก็ตามเครื่องมือมีราคาแพง ข้อดีอีกอย่างหนึ่งคือกระบวนการลบสามารถตรวจสอบได้ง่ายขึ้นด้วยเครื่องมือประเภทนี้ หากไม่มีเครื่องมือการจำลองแบบคุณจะต้องสร้างตารางตรวจสอบและทริกเกอร์ไฟสำหรับการลบ - ไม่ใช่วิธีปฏิบัติที่ดีในความคิดของฉัน

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

มีเหตุผลทางธุรกิจอื่น ๆ อีกมากมายในการใส่ 2 วันนี้ซึ่งฉันจะไม่เจาะลึกลงไปที่นี่ ทำการบ้านของคุณและฉันแน่ใจว่า 3-6-12-48 เดือนตามถนนคุณจะมีความสุขมากที่คุณใส่ใน 2 ฟิลด์ง่ายๆเหล่านี้

ฉันได้ดำเนินการแล้วและมักจะแนะนำวิธีแก้ปัญหาทั้งสองอย่างหากทำได้


5

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

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

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

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


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

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

4

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

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

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


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

1

นี่เป็นเรื่องที่ค่อนข้างง่ายที่จะติดตั้ง (อาจรวม 1 ถึง 3 วัน) ดังนั้นในความคิดของฉันมันมีค่าเท่าใดที่จะเพิ่มลงในใบสมัครของคุณตลอดช่วงชีวิตของมัน

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

ประการที่สองสำหรับคอลัมน์โดยใช้ค่าเริ่มต้นเช่น GetUTCDate () (SQL Server, Oracle อาจแตกต่างกัน) แก้ไขการเข้ารหัสเพิ่มเติมใด ๆ ในการแทรกดังนั้นรหัสฐานไม่ต้องเปลี่ยนสำหรับงบแทรกใด ๆ เนื่องจากค่าเริ่มต้นจะเป็น ใช้

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

อาจมีโค้ดสคริปต์ sql จำนวนมาก (ขึ้นอยู่กับจำนวนตาราง) แต่เป็นรูปแบบที่สามารถทำซ้ำได้ดังนั้นคุณสามารถสร้างโค้ดโดยดูที่สกีมา DB ที่มีอยู่


ฉันกังวลว่าด้วยแนวทางวงใหญ่เช่นว่าคุณจะมีปัญหาการบำรุงรักษาในระยะยาวกับตารางใหม่หรือ (ยิ่งแย่กว่านั้น) คุณจะต้องสร้าง sproc ที่สแกนแต่ละตารางเพื่อหาคอลัมน์ที่มีชื่อที่แน่นอน สคริปต์ DDL เพื่อเพิ่มพวกเขาหากขาดหายไปซึ่งฟังดูเหมือนฝันร้ายในการบำรุงรักษา!
Ed James

หากนี่เป็นมาตรฐานหวังว่านักพัฒนาจะสร้างตารางใหม่ตามมาตรฐาน มิฉะนั้นฝันร้าย วิธีการคือการทำให้ schema ที่มีอยู่นั้นมีความเร็วสูงสุดหลังจากนั้นความรับผิดชอบก็อยู่ที่นักพัฒนาเพื่อให้เป็นไปตามมาตรฐาน
Jon Raynor

ฉันคิดว่าคำสำคัญในความคิดเห็นนั้นคือ "หวังว่า" ฉันไม่แน่ใจว่าฉันเชื่อมั่นในสิ่งที่เกิดขึ้นจากความตั้งใจของนักพัฒนาใหม่แต่ละคน!
Ed James

2
@Ed - ตกลงไม่ไว้วางใจนั่นคือสิ่งที่ความคิดเห็นรหัสมีไว้สำหรับ! :)
Jon Raynor
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.