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

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

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

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

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

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

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

ผมพบว่าเชื่อมโยงไปยังเก่า แต่ที่น่าสนใจเอกสารโดย ESRI ระบุ9 เหตุผลที่จะเลือก File กว่า GDB เป็นที่น่าสนใจที่จะเรียกเฉพาะประสิทธิภาพเป็นเหตุผลหนึ่ง ส่วนหนึ่งของประสิทธิภาพที่เพิ่มขึ้นนี้เกิดจากระบบจัดเก็บไฟล์ ฉันคิดว่านี่อาจเป็นเพราะขาดการสนับสนุนหลายคอลัมน์ ไม่เหมือนกับใน Personal GDB ซึ่งเป็นไฟล์เดียวดัชนีในไฟล์ GDB จะถูกจัดเก็บเป็นไฟล์แยกต่างหากในโครงสร้าง GDB ซึ่งหมายความว่าไฟล์ดัชนีและไฟล์แอตทริบิวต์สำหรับ featureclass เฉพาะจะต้องมีการเชื่อมโยงและเข้าถึงด้วยกัน ฉันสามารถดูได้ว่าดัชนีแบบหลายคอลัมน์จะนำไปสู่การข้ามไปมาระหว่างดัชนีและไฟล์แอตทริบิวต์และอาจทำให้ประสิทธิภาพการทำงานที่เพิ่มขึ้นเมื่อเทียบกับการเพิ่มประสิทธิภาพการทำดัชนี

เนื่องจากมีการเพิ่มประสิทธิภาพการทำงานอย่างมีนัยสำคัญกับไฟล์ GDB ผ่าน GDB ส่วนบุคคลจึงอาจไม่คุ้มค่าที่จะใช้ดัชนีหลายคอลัมน์

จากประสบการณ์ของฉันที่ทำงานกับ GDB ทั้งสองชนิดฉันได้เห็น GDB ส่วนบุคคลทำงานมากกว่าไฟล์ประมาณ 50% จากข้อมูลที่คุณให้เกี่ยวกับไฟล์ GDB ของคุณหากคุณต้องการแปลงเป็น PGDB คุณอาจจะต้องจบลงด้วย GDB ส่วนตัว ~ 300MB จากสิ่งที่ฉันได้เห็นการทำงานกับฐานข้อมูล MS Access ทั้งภายในผลิตภัณฑ์ ESRI และแยกกันคือคุณเริ่มเห็นการลดลงของประสิทธิภาพเมื่อไฟล์ ".mdb" เพิ่มขึ้นอย่างมีนัยสำคัญมากกว่า 100MB ในขนาด

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

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

มีเหตุผลสำคัญอย่างน้อย9 ข้อในการใช้ไฟล์ Geodatabase ผ่าน Personal Geodatabase น่าเสียดายที่ยังมีเหตุผลอีกมากมายที่จะต้องรักษา PGDB เก่าไว้; ภาวะที่กลืนไม่เข้าคายไม่ออกของคุณเป็นหนึ่งในพวกเขา (ไม่มีการเผยแพร่ ESRI ในหัวข้อนี้)

ฉันเชื่อว่าจุดประสงค์หลักของ FGDB เหนือ PGDB คือความจุในการจัดเก็บและประสิทธิภาพของข้อมูลอวกาศ (ความเร็วในการดึง, การดึง, การทำดัชนีเชิงพื้นที่, การสอบถามเชิงพื้นที่เป็นต้น) แทนที่จะใช้ฟังก์ชันเช่นดัชนี "attribute" หลายคอลัมน์และฟังก์ชัน SQL ขั้นสูงอื่น ๆ โดยปกติจะเป็นส่วนสำคัญของ DBMS ใด ๆ (ซึ่ง PGDB ที่ใช้การเข้าถึง MSDB คือและ FGDB ดั้งเดิมของ ESRI ไม่ใช่) เป็นบันทึกย่อ ขีด จำกัด ขนาดไฟล์สูงสุดของฐานข้อมูล MS Access คือ 2GB ซึ่งเป็นขนาดสูงสุดของ PGDB ใด ๆ ในทางตรงกันข้ามขีด จำกัด ขนาดไฟล์ FGDB คือ 1TB พอที่จะใช้กับ 256TB

ESRI ยังระบุด้วยว่า: ไวยากรณ์ที่คุณใช้สร้างนิพจน์ SQL นั้นแตกต่างกันไปตามแหล่งข้อมูล นี่เป็นเพราะถึงแม้ว่า SQL จะเป็นมาตรฐาน แต่ซอฟต์แวร์ฐานข้อมูลทั้งหมดนั้นใช้ภาษาของ SQL เดียวกัน และในการสืบค้นข้อมูลจากไฟล์รวมถึงฐานข้อมูลทางภูมิศาสตร์ของไฟล์การครอบคลุมรูปร่างของไฟล์ตาราง INFO ตาราง dBASE, CAD และ VPF ข้อมูลคุณใช้ภาษาของ SQL ที่นำมาใช้ภายใน ArcGIS ที่สนับสนุนชุดย่อยของคุณสมบัติและฟังก์ชั่นส่วนบุคคลและ ฐานข้อมูล Geod ArcSDE

ในคำอื่น ๆ (และ PGDB และ ArcSDE GDB เป็นหลักฐานการนั้น) ถ้า geodatabase พื้นฐาน DBMS สนับสนุนการทำงานนี้แล้วมันควรจะมี นี่เป็นเหตุผลที่คุณสามารถสร้างดัชนีหลายคอลัมน์ใน PGDB ที่มีฐานข้อมูล MS Access อยู่ เช่นเดียวกันกับฐานข้อมูลภูมิศาสตร์ ArcSDE ใด ๆ ที่มี DBMS พื้นฐานซึ่งรองรับฟังก์ชั่นนี้

สำหรับไฟล์ Geodabase ; ที่9.2 FGDB รีลีส ESRIระบุว่าฟีเจอร์และฟังก์ชั่นเหล่านี้บางอย่างอาจถูกเพิ่มในรีลีส FGDB ในอนาคตการอ้างถึง; "ฐานข้อมูลไฟล์ทางภูมิศาสตร์ไม่รองรับคุณสมบัติและฟังก์ชั่นทั้งหมดที่มีอยู่สำหรับฐานข้อมูลส่วนบุคคลทางภูมิศาสตร์ที่ ArcGIS 9.2 ฟังก์ชั่นที่ใช้บ่อยที่สุดที่ไม่รองรับโดยฐานข้อมูลทางภูมิศาสตร์ของไฟล์ ได้แก่ DISTINCT, GROUP BY และ ORDER BY MAX และ SUM ไม่ได้รับการสนับสนุนภายนอกเคียวรีย่อยการสนับสนุนบางอย่างอาจมีการเพิ่มในการเผยแพร่ในอนาคต "

สี่ปีต่อมาในเวอร์ชัน 10 ไม่มีฟังก์ชั่นและคุณสมบัติเหล่านี้ ( รายการฟังก์ชั่นที่มี )

ดูเหมือนว่า FGDB เป็นงานที่อยู่ระหว่างดำเนินการและต้องการความสามารถในการทำดัชนีแบบหลายคอลัมน์ได้มากเท่าที่ต้องการฟังก์ชัน SQL DBMS ที่จำเป็นทั้งหมด ฉันเดาว่าเราจะติดอยู่กับ PGDB จนกว่าผู้พัฒนา ESRI จะตัดสินใจว่าเป็นสิ่งสำคัญที่จะต้องขยายการทำงานไปยัง FGDB

การคืนค่าเธรด / ปัญหานี้ฉันพบว่าสามารถเป็นประโยชน์ในการรวมเข้าด้วยกันหากเป็นไปได้ FGDB และ PGDB ตัวอย่างเช่นสร้าง scratch-geodatabase เป็น PGDB ซึ่งช่วยในการค้นหาอย่างมาก ขนาดของ PGDB ไม่ควรเพิ่มมากเกินไปดังที่กล่าวไว้ข้างต้น