คำถามติดแท็ก recursive

2
การใช้ข้อยกเว้นในนิพจน์ตารางแบบเรียกซ้ำ
เหตุใดแบบสอบถามต่อไปนี้จึงส่งกลับแถวที่ไม่มีที่สิ้นสุด ฉันคาดว่าจะมีEXCEPTประโยคที่จะยุติการสอบถามซ้ำ .. with cte as ( select * from ( values(1),(2),(3),(4),(5) ) v (a) ) ,r as ( select a from cte where a in (1,2,3) union all select a from ( select a from cte except select a from r ) x ) select a from r ฉันเจอสิ่งนี้ในขณะที่พยายามตอบคำถามเกี่ยวกับ …

4
การเรียกใช้ SQL ซ้ำใช้งานได้จริงอย่างไร
เมื่อมาถึง SQL จากภาษาการเขียนโปรแกรมอื่นโครงสร้างของเคียวรีแบบเรียกซ้ำจะค่อนข้างแปลก เดินผ่านทีละขั้นตอนและดูเหมือนว่าจะกระจุย ลองพิจารณาตัวอย่างง่ายๆดังต่อไปนี้: CREATE TABLE #NUMS (N BIGINT); INSERT INTO #NUMS VALUES (3), (5), (7); WITH R AS ( SELECT N FROM #NUMS UNION ALL SELECT N*N AS N FROM R WHERE N*N < 10000000 ) SELECT N FROM R ORDER BY N; ลองเดินดูกัน ขั้นแรกสมาชิกจุดยึดดำเนินการและชุดผลลัพธ์ถูกใส่ใน R ดังนั้น R …

5
วิธีหาช่องว่างซ้ำ ๆ เมื่อ 90 วันที่ผ่านไประหว่างแถว
นี่เป็นงานที่ไม่สำคัญใน C # โฮมเวิร์ลดของฉัน แต่ฉันยังไม่ได้ทำใน SQL และต้องการที่จะแก้ปัญหาการตั้งค่า (โดยไม่มีเคอร์เซอร์) ชุดผลลัพธ์ควรมาจากข้อความค้นหาเช่นนี้ SELECT SomeId, MyDate, dbo.udfLastHitRecursive(param1, param2, MyDate) as 'Qualifying' FROM T มันควรจะทำงานอย่างไร ฉันส่ง params ทั้งสามนี้ไปยัง UDF UDF ใช้ params ภายในเพื่อดึงข้อมูลแถว <= 90 วันที่เก่ากว่าที่เกี่ยวข้องจากมุมมอง UDF สำรวจ 'MyDate' และส่งคืน 1 ถ้าควรรวมอยู่ในการคำนวณทั้งหมด หากไม่ควรส่งคืนค่า 0 จะถูกตั้งชื่อเป็น "คุณสมบัติ" สิ่งที่ udf จะทำ แสดงรายการแถวตามลำดับวันที่ คำนวณวันระหว่างแถว แถวแรกในชุดผลลัพธ์เป็น Hit = 1 …

2
วนซ้ำ CTE เพื่อหาผลรวมสำหรับเด็กทุกคน
นี่คือต้นไม้ประกอบที่ฉันต้องการค้นหาโดยใช้T-SQLแบบสอบถามซ้ำ(สมมุติCTE) ด้วยผลลัพธ์ที่คาดหวังด้านล่าง ฉันต้องการที่จะรู้จำนวนรวมต่อการชุมนุมที่ได้รับส่วนใดส่วนหนึ่ง หมายความว่าถ้าฉันค้นหา 'หมุดย้ำ' ฉันต้องการทราบจำนวนรวมในแต่ละระดับภายในการชุมนุมไม่ใช่เฉพาะจำนวนลูกโดยตรง Assembly (id:1) | |-Rivet |-Rivet |-SubAssembly (id:2) | | | |-Rivet | |-Bolt | |-Bolt | |-SubSubAssembly (id:3) | | | |-Rivet | |-Rivet | |-SubAssembly (id:4) |-Rivet |-Bolt DESIRED Results ------- ID, Count 1 , 6 2 , 3 3 , 2 4 …

2
ความลึกของลูกหลานแบบเรียกซ้ำ PostgreSQL
ฉันต้องคำนวณความลึกของลูกหลานจากบรรพบุรุษของมัน เมื่อมีการบันทึกobject_id = parent_id = ancestor_idจะถือว่าเป็นโหนดรูท (บรรพบุรุษ) ผมได้พยายามที่จะได้รับWITH RECURSIVEการสอบถามการทำงานกับ PostgreSQL 9.4 ฉันไม่ได้ควบคุมข้อมูลหรือคอลัมน์ data และ schema ของตารางมาจากแหล่งภายนอก ตารางจะเติบโตอย่างต่อเนื่อง ตอนนี้บันทึกประมาณ 30k ต่อวัน โหนดใด ๆ ในทรีสามารถหายไปและพวกเขาจะถูกดึงจากแหล่งภายนอกในบางจุด พวกเขามักจะถูกดึงcreated_at DESCตามลำดับ แต่ข้อมูลจะถูกดึงด้วยงานพื้นหลังแบบอะซิงโครนัส เริ่มแรกเรามีวิธีแก้ไขปัญหาของรหัส แต่ตอนนี้มี 5M + แถวใช้เวลาเกือบ 30 นาทีจึงจะเสร็จสมบูรณ์ ตัวอย่างคำจำกัดความของตารางและข้อมูลการทดสอบ: CREATE TABLE objects ( id serial NOT NULL PRIMARY KEY, customer_id integer NOT NULL, object_id integer …

1
จะกรองการใช้ฟังก์ชันที่ผู้ใช้กำหนดเองของ Scalar จากข้อมูลการตรวจสอบเซิร์ฟเวอร์ SQL ได้อย่างไร
เรามีฐานข้อมูล SQL Server ซึ่งมีข้อกำหนดการตรวจสอบฐานข้อมูลที่ตรวจสอบการดำเนินการทั้งหมดในฐานข้อมูล CREATE DATABASE AUDIT SPECIFICATION [dbAudit] FOR SERVER AUDIT [servAudit] ADD (EXECUTE ON DATABASE::[DatabaseName] BY [public]) เราพบว่าแบบสอบถามบางข้อจะเขียนลงในบันทึกการตรวจสอบโดยใช้ฟังก์ชั่นสเกลาร์สำหรับทุกแถวในชุดผลลัพธ์ เมื่อสิ่งนี้เกิดขึ้นบันทึกจะเต็มก่อนที่เราจะสามารถ ETL ลงในที่ซึ่งเป็นสถานที่พักผ่อนขั้นสุดท้ายและเรามีช่องว่างในการบันทึกของเรา น่าเสียดายเนื่องจากเหตุผลด้านความสอดคล้องเราไม่สามารถหยุดการตรวจสอบทุกEXECUTEคำสั่งได้ ความคิดแรกของเราสำหรับแนวทางในการแก้ไขปัญหานี้คือการใช้WHEREข้อในการตรวจสอบเซิร์ฟเวอร์เพื่อกรองกิจกรรม รหัสดูเหมือนว่านี้: WHERE [object_id] not in (Select object_id from sys.objects where type = 'FN' ) น่าเสียดายที่ SQL Server ไม่อนุญาตให้ตัวดำเนินการสัมพันธ์ (อาจเป็นเพราะมันไม่ต้องการสอบถามทุกครั้งที่มีการเขียนไปยังบันทึกการตรวจสอบ) เราต้องการหลีกเลี่ยงการเขียน proc ที่เก็บไว้ซึ่งเป็นรหัสที่ยากobject_idในWHEREข้อ แต่นั่นคือความคิดของเราในปัจจุบันเกี่ยวกับวิธีที่ดีที่สุดในการแก้ไขปัญหานี้ มีวิธีอื่นที่เราควรพิจารณาหรือไม่? เราสังเกตเห็นว่าเมื่อฟังก์ชั่นสเกลาร์ถูกใช้ใน …

1
ฉันจะจัดเรียงผลลัพธ์ของข้อความค้นหาแบบเรียกซ้ำในลักษณะคล้ายต้นไม้แบบขยายได้อย่างไร
สมมติว่าคุณมีnodesตารางแบบนี้: CREATE TABLE nodes ( node serial PRIMARY KEY, parent integer NULL REFERENCES nodes(node), ts timestamp NOT NULL DEFAULT now() ); มันแสดงให้เห็นถึงโครงสร้างต้นไม้เหมือนโหนดมาตรฐานที่มีรูตโหนดที่ด้านบนและโหนดเด็กหลายห้อยจากโหนดรูทหรือโหนดเด็กอื่น ๆ ให้เราแทรกค่าตัวอย่างสองสามค่า: INSERT INTO nodes (parent) VALUES (NULL), (NULL), (NULL), (NULL), (1), (1), (1), (1), (6), (1) , (6), (9), (6), (6), (3), (3), (3), (15); ตอนนี้ฉันต้องการเรียกรูต 10 …

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

2
แนวความคิด ERD หลายโต๊ะหลายคนหรืออาจจะวนซ้ำ?
ฉันกำลังสร้างไดอะแกรมเชิงแนวคิด [ใช่ฉันรู้ว่าฉันได้รวมคุณลักษณะและปุ่ม - แต่นี่เป็นเพียงสำหรับฉันที่จะรวมสิ่งที่ฉันทำในขณะที่เรียนรู้] - ดังนั้นโปรดรักษามันเป็นแนวคิดด้วยการมุ่งเน้นที่ความสัมพันธ์และ ตารางและไม่ใช่วิธีไดอะแกรม;) สิ่งกีดขวางในใจของฉันคือ: ฉันพยายามที่จะหาวิธีที่ดีที่สุดในการสร้างแบบจำลองความสัมพันธ์ส่วนตัวที่ตั้งและองค์กร ก่อนอื่นกฎ: หนึ่งหรือมากกว่าส่วนตัว 's สามารถเป็นสมาชิก / เพื่อนของหนึ่งหรือมากกว่าองค์กร ; และในทางกลับกัน. โปรไฟล์อย่างน้อยหนึ่งรายการสามารถเป็นสมาชิก / เพื่อนของโปรไฟล์อื่น ๆ องค์กรอย่างน้อยหนึ่งแห่งสามารถเป็นสมาชิก / เพื่อนขององค์กรอื่น ๆ ได้ เพื่อนและสมาชิกแตกต่างกันในการที่เพื่อนเป็นแบบอ่านอย่างเดียวและสมาชิก [ขึ้นอยู่กับระดับ] สามารถเข้าถึงสิ่งที่แก้ไขได้อย่างเต็มที่ เพื่อให้สิ่งต่าง ๆ ซับซ้อนขึ้นสถานที่ตั้งมีกฎการรีฟิล "เพิ่มเติม" ของตนเองเช่นองค์กรที่เป็นเจ้าของสองสถานที่แต่ขึ้นอยู่กับกฎที่ตั้งสมาชิก [ โปรไฟล์ ] ขององค์กรนั้นอาจเข้าถึงได้อย่างเต็มที่ในที่เดียว แต่ จำกัด การเข้าถึงที่ อื่น ๆ [ขออภัย: คุณมักจะต้องเปิดภาพในหน้าต่างอื่นเพื่อดูขนาดที่ดีขึ้น] ดังนั้นอย่างที่คุณเห็นแนวคิดของโปรไฟล์และองค์กรนั้นเหมือนกันเช่นเดียวกับแนวคิดที่ยังไม่ได้เป็นแบบอย่างของเพื่อนและสมาชิก [... ซึ่งฉันคิดว่าจะได้รับการจัดการเหมือนตารางตัวกลางปัจจุบันที่มีการตั้งค่าเจ้าของ / ผู้ดูแลระบบ …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.