ผู้ดูแลฐานข้อมูล

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

2
วิธีการเปลี่ยนจาก SQL Server DBA เป็น Oracle
หากฉันต้องการเปลี่ยนจาก SQL Server DBA ไปเป็น Oracle สิ่งที่จะเป็นการเรียนรู้ที่สำคัญหรือไม่น่าสนใจที่ฉันต้องทำ ฉันคิดว่าแนวคิดเหมือนกันและความแตกต่างเป็นเพียงภาษาโปรแกรม แต่ฉันไม่ได้เห็นอีกด้านหนึ่งของประตู

8
IntelliSense ไม่ทำงาน แต่เปิดใช้งานแล้ว
ปัญหานี้พิสูจน์ให้เห็นแล้วว่าเป็นเรื่องยุ่งยาก (และค่อนข้างน่ารำคาญ) ใน SQL Server Management Studio 2008 จนถึงไม่กี่วันที่ผ่านมา IntelliSense ของฉันทำงานได้ดี ทันใดนั้นมันก็หยุด ไอคอนตามที่เปิดใช้งานบนเมนูแถบเครื่องมือและภายใต้เครื่องมือ -> ตัวเลือก -> ตัวแก้ไขข้อความ -> T-SQL -> IntelliSense ระบุว่ามีการเปิดใช้งานที่นั่น ฉันลอง refeshing แคช IntelliSense ด้วย Ctrl-Shft-R แต่ก็ไม่ได้ผลเหมือนกัน ความคิดใด ๆ ที่เกิดขึ้นกับ IntelliSense ของฉันและสิ่งที่ฉันต้องทำเพื่อให้ได้กลับมา?

7
เกณฑ์การจับคู่ขั้นต่ำอะไรที่แนะนำสำหรับการจับคู่ผู้ป่วยด้วยข้อมูลประชากรที่เชื่อถือได้
เมื่อจับคู่ผู้ป่วยตามข้อมูลประชากรมีคำแนะนำใด ๆ เกี่ยวกับเขตข้อมูลใดที่ควรจับคู่กับผู้ป่วยให้เป็น "ผู้ป่วยรายเดียวกัน" ฉันรู้ว่าอัลกอริทึมจะแตกต่างกันสำหรับการใช้งานที่แตกต่างกันฉันแค่อยากรู้ว่ามีวิธีปฏิบัติที่ดีที่สุดหรือคำแนะนำเกี่ยวกับกระบวนการนี้ First Name Last Name Date of Birth SSN Address City State Zip etc?
30 identity 

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

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

3
การกำหนดค่า PostgreSQL สำหรับประสิทธิภาพการเขียน
เซิร์ฟเวอร์ PostgreSQL ของฉันหนึ่งโฮสต์หลายฐานข้อมูล (1-3) ที่ได้รับกระแสข้อมูลคงที่ ข้อมูลไม่ได้ถูกจัดโครงสร้างโดยเฉพาะอย่างยิ่งมันเป็นจำนวนเวลาปัจจุบันและความหลากหลายของข้อมูลที่สังเกตสำหรับการทันทีนั้น อัตราข้อมูลค่อนข้างสูง มันทำงานได้ประมาณกิกะไบต์ต่อวันสำหรับฐานข้อมูลหนึ่งประมาณหนึ่งในสิบของฐานข้อมูลอื่น ฉันไม่คาดหวังว่าอัตรานี้จะเพิ่มขึ้น ประสิทธิภาพการอ่านมีความสำคัญต่ำกว่ามากและเป็นที่ยอมรับในปัจจุบัน ในบันทึกฉันมีข้อความนี้: LOG: checkpoints are occurring too frequently (15 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". ค่านี้ตั้งไว้ที่ 16 pgtuneซึ่งเป็นมารยาทของ การตั้งค่าใดที่ฉันควรพิจารณาเพื่อปรับปรุงประสิทธิภาพการเขียน ฉันต้องการที่จะรักษาความปลอดภัยให้มากที่สุด เมื่อพิจารณาจากปริมาณข้อมูลที่เข้ามาฉันสามารถยอมรับการสูญเสียข้อมูลล่าสุดในความล้มเหลวตราบใดที่ข้อมูลจำนวนมากไม่เสียหาย แก้ไข: ฉันใช้ PostgreSQL 9.0 ในตอนนี้ แต่ฉันวางแผนที่จะอัพเกรดเป็น 9.1 ฉันไม่ได้โพสต์รายละเอียดฮาร์ดแวร์เพราะในขณะที่ฉันรับทราบความสำคัญของพวกเขาในที่สุดฉันจะต้องทำให้การเพิ่มประสิทธิภาพนี้ในหลายเครื่องด้วยฮาร์ดแวร์ที่หลากหลายมาก หากฮาร์ดแวร์มีความสำคัญต่อคำตอบโปรดให้ข้อมูลทั่วไปเพื่อให้ฉันสามารถใช้คำตอบกับเครื่องที่มีการกำหนดค่าฮาร์ดแวร์ที่แตกต่างกัน

3
ทำคอลัมน์ซ้ำเพื่อการสืบค้นที่เร็วขึ้นไหม
ชื่อเรื่องไม่สมเหตุสมผล แต่ฉันไม่สามารถคิดชื่อที่ดีกว่าสำหรับปัญหานี้ได้ ฉันมีตารางต่อไปนี้ โครงการ รหัส ชื่อ ลูกค้า รหัส id_project ชื่อ การชำระเงิน รหัส id_customer วันที่ รวม เมื่อผู้ใช้เข้าสู่ระบบเขาจะสามารถเข้าถึงโครงการบางอย่างได้ ตอนนี้ฉันต้องการแสดงรายการการชำระเงินทั้งหมดสำหรับโครงการนั้นและควรง่าย: SELECT FROM payments where id_customer in (SELECT id from customers where id_project = 5) คำถามของฉันคือ: หากการเพิ่มคอลัมน์ id_project ในตารางการชำระเงินไม่ดีกว่าวิธีนี้จะทำให้การสืบค้นง่ายขึ้นและเร็วขึ้น

10
วิธีที่มีประสิทธิภาพในการติดฉลากคอลัมน์ในฐานข้อมูลคืออะไร?
ฉันเคยติดป้ายกำกับคอลัมน์ในฐานข้อมูลของฉันเช่นนี้: user_id user_name user_password_hash เพื่อหลีกเลี่ยงความขัดแย้งเมื่อเข้าร่วมสองตาราง แต่จากนั้นฉันเรียนรู้เพิ่มเติมเกี่ยวกับวิธีนามแฝงตารางและฉันหยุดทำสิ่งนี้ วิธีที่มีประสิทธิภาพในการติดฉลากคอลัมน์ในฐานข้อมูลคืออะไร? ทำไม?

3
คีย์หลักของอักขระเทียบกับจำนวนเต็ม
ฉันกำลังออกแบบฐานข้อมูลด้วยตารางการค้นหาหลายตารางที่มีคุณลักษณะที่เป็นไปได้ของเอนทิตีหลัก ฉันกำลังคิดที่จะใช้คีย์ 4 หรือ 5 ตัวอักษรเพื่อระบุค่าการค้นหาเหล่านี้แทนที่จะเป็นจำนวนเต็มที่เพิ่มขึ้นโดยอัตโนมัติดังนั้นเมื่อฉันเก็บ ID แอตทริบิวต์เหล่านี้ไว้ในตารางหลักฉันจะเห็นค่าที่มีความหมายมากกว่าแค่ตัวเลขสุ่ม ความหมายด้านประสิทธิภาพของการใช้ฟิลด์อักขระเป็นคีย์หลักแทนที่จะเป็นจำนวนเต็มมีอะไรบ้าง ฉันใช้ MySQL ถ้าเรื่องนั้น [แก้ไข] ตารางค้นหาเหล่านี้มีการเพิ่มระเบียนใหม่นาน ๆ ครั้ง พวกเขาจะดูแลด้วยตนเองและคีย์ตามตัวอักษรจะถูกสร้างขึ้นด้วยตนเองเช่นกัน นี่คือตัวอย่าง: CUISINES ID Description ----- -------------- CHNSE Chinese ITALN Italian MXICN Mexican

2
ปรับแต่งแบบสอบถาม Postgres ด้วย IN ขนาดใหญ่
ข้อความค้นหานี้รับรายการโพสต์ที่สร้างโดยคนที่คุณติดตาม คุณสามารถติดตามคนได้ไม่ จำกัด จำนวน แต่คนส่วนใหญ่ติดตามน้อยกว่า 1,000 คน ด้วยการสืบค้นแบบนี้การเพิ่มประสิทธิภาพที่เห็นได้ชัดคือการแคช"Post"รหัส แต่น่าเสียดายที่ฉันไม่มีเวลาสำหรับตอนนี้ EXPLAIN ANALYZE SELECT "Post"."id", "Post"."actionId", "Post"."commentCount", ... FROM "Posts" AS "Post" INNER JOIN "Users" AS "user" ON "Post"."userId" = "user"."id" LEFT OUTER JOIN "ActivityLogs" AS "activityLog" ON "Post"."activityLogId" = "activityLog"."id" LEFT OUTER JOIN "WeightLogs" AS "weightLog" ON "Post"."weightLogId" = "weightLog"."id" LEFT …

3
ทำไมดัชนี REBUILD ไม่ลดการแยกส่วนดัชนี?
ฉันใช้ ALTER INDEX REBUILD เพื่อลบการแตกแฟรกเมนต์ดัชนี ในบางกรณี REBUILD ดูเหมือนจะไม่ลบการกระจายตัวของนี้ อะไรคือสาเหตุที่ REBUILD ไม่ลบการแยกส่วน? ดูเหมือนว่าสิ่งนี้จะเกิดขึ้นโดยเฉพาะกับดัชนีขนาดเล็ก

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

4
วิธีการย้ายฐานข้อมูลจาก SQL Server 2012 ไปยัง SQL Server 2005
ตัวเลือกของฉันคืออะไรถ้าฉันต้องการย้ายฐานข้อมูลจาก SQL Server 2012 (32 บิต) ไปยัง SQL Server 2005 (64 บิต) ฉันรู้ว่าฉันไม่สามารถ: คืนค่าการสำรองข้อมูลของฐานข้อมูลบน SQL Server 2005 แยกออกและแนบ ฉันรู้ว่าฉันสามารถ: ใช้ตัวช่วยสร้างการนำเข้าข้อมูลและฉันลองใช้กับฐานข้อมูลเดียว แต่ย้ายข้อมูลเท่านั้นและแม้จะเป็นปัญหาเพราะฉันต้องทำงานมากในการสร้างตาราง temp เพื่อรักษาคอลัมน์ข้อมูลประจำตัวสร้าง FKs ใหม่ทั้งหมดดัชนีเป็นต้น มีตัวเลือกง่ายขึ้นไหม


5
DELETE ช้ามากใน PostgreSQL หรือไม่?
ฉันมีฐานข้อมูลบน PostgreSQL 9.2 ที่มีคีมาหลักที่มีประมาณ 70 ตารางและจำนวนตัวแปรของสกีมาต่อไคลเอนต์ที่มีโครงสร้างเหมือนกันจำนวน 30 ตาราง สกีมาไคลเอนต์มีคีย์ต่างประเทศอ้างอิงถึงสกีมาหลักและไม่ใช่วิธีอื่น ๆ ฉันเพิ่งเริ่มเติมฐานข้อมูลด้วยข้อมูลจริงบางอย่างที่นำมาจากเวอร์ชันก่อนหน้า ฐานข้อมูลมาถึงประมาณ 1.5 GB (คาดว่าจะเพิ่มขึ้นเป็น 10s GB ภายในไม่กี่สัปดาห์) เมื่อฉันต้องทำการลบจำนวนมากในตารางกลางในสคีมาหลัก คีย์ต่างประเทศที่เกี่ยวข้องทั้งหมดจะถูกทำเครื่องหมายว่า DELETE CASCADE ไม่แปลกใจเลยว่าจะใช้เวลานาน แต่หลังจากผ่านไป 12 ชั่วโมงก็เห็นได้ชัดว่าฉันเริ่มต้นได้ดีกว่าปล่อย DB และเรียกใช้การย้ายข้อมูลอีกครั้ง แต่ถ้าฉันต้องทำซ้ำการดำเนินการนี้ในภายหลังเมื่อฐานข้อมูลมีชีวิตอยู่และมีขนาดใหญ่ขึ้น? มีวิธีอื่นให้เลือกเร็วกว่านี้ไหม? มันจะเร็วกว่านี้ไหมถ้าฉันเขียนสคริปต์ที่จะเรียกดูตารางที่ขึ้นต่อกันเริ่มต้นที่ตารางที่ไกลที่สุดจากตารางกลางการลบตารางแถวที่อยู่ต่อกันทีละตาราง? รายละเอียดที่สำคัญคือมีทริกเกอร์ในบางตาราง

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