กำหนด id เฉพาะให้กับคุณสมบัติจุด

มาตรฐานพัสดุ MassGIS (http://www.mass.gov/mgis/ParstndrdVer1_5_1.pdf) ใช้การเชื่อมต่อของส่วนจำนวนเต็มทั้งหมดของ x- และพิกัด y เพื่อสร้าง id เฉพาะ (LOC_ID) สำหรับคุณสมบัติ ฉันกำลังพิจารณาที่จะทำแบบเดียวกันกับคลาสฟีเจอร์แต้ม ฉันชอบวิธีการที่สอดคล้องกัน แต่บางทีฉันอาจมองเห็นบางสิ่งบางอย่าง มีมาตรฐานหรือวิธีปฏิบัติที่ดีที่สุดสำหรับการสร้างรหัสเฉพาะสำหรับคุณสมบัติจุด

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

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

/ Nicklas

เพิ่มในจากคำตอบของ Nicklas และความคิดเห็นของฉัน

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

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

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

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

คำถามติดตาม: มันเป็นวิธีที่ดีที่สุดในการสร้างและรักษา id ที่ไม่ซ้ำกันใน DBMS (SQL Server) หรือในซอฟต์แวร์ GIS (ArcGIS)?

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

รูปแบบการระบุตัวตนของเราไม่ได้ถูกเลือกโดยฉัน แต่มีดังต่อไปนี้: รหัสตัวอักษร 2,3,4 ซึ่งเป็นประเภทของสินทรัพย์และหมายเลขลำดับ 6 หลัก (คุณจะเลือกจำนวนหลักที่เหมาะกับคุณ) กระบวนงานที่เก็บไว้จะสร้าง ID เหล่านี้และอาศัยตารางที่ไม่ใช่ฐานข้อมูลสองตารางในฐานข้อมูล SQL Server เดียวกัน

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

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

ก่อนหน้านี้ฉันเคยใช้การคำนวณ CRC มาก่อนเพื่อสร้างค่าที่คล้ายกัน สร้างและไลบรารี / อัลกอริทึมไม่ได้ยากเกินไปออนไลน์

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

และฉันคิดว่ามันไม่น่าเป็นไปได้ที่ผู้ใช้ปลายทางจะค้นหาด้วย ID นี้ต่อไปดังนั้นฉันจึงไม่เห็นว่าเป็นปัญหา

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

"แน่นอนว่า GUID สามารถสร้างขึ้นได้โดยใช้ VB Script แต่ด้วยการค่อยๆทยอยของ VB Script โดย ESRI เราจะดำเนินการสร้าง GUID ใน ArcMap โดยใช้สิ่งมหัศจรรย์ที่เก้าของโลก Python สำหรับผู้ที่ไม่ได้อยู่ใน รู้ไหมหลามเป็นของขวัญจากพระเจ้าในการแฮ็กเกอร์ GIS ที่ไม่เคยมีมาก่อนคำแนะนำของฉัน: เรียนรู้! ใช้ชีวิต! รักมันมาก! "

http://eaglemap.com/blog/bid/45555/How-to-Generate-GUIDs-in-ArcMap

Arc Hydro Toolsของ ESRI มาพร้อมกับแถบเครื่องมือที่ติดตั้งตัวจัดการ ID ที่ไม่ซ้ำใครซึ่งทำงานในพื้นหลัง แถบเครื่องมือช่วยให้คุณสามารถกำหนด ID ที่ไม่ซ้ำกันต่อคลาสสถานที่หรือต่อฐานข้อมูลทางภูมิศาสตร์ ตัวจัดการ ID ต่อค่าเริ่มต้นจะจัดการแอตทริบิวต์ ID เฉพาะที่เรียกว่า HydroID ซึ่งเป็นส่วนหนึ่งของรูปแบบข้อมูล Arc Hydro แต่สามารถตั้งค่าให้จัดการกับคุณสมบัติอื่น ๆ ได้เช่นกัน เครื่องมือมาพร้อมกับเอกสารจำนวนมากดังนั้นการกำหนดค่าตัวจัดการ ID ตามความต้องการของคุณไม่ควรเป็นปัญหา

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

ตัวจัดการ ID ที่ไม่ซ้ำกันอาจมีประโยชน์สำหรับแบ็กเอนด์ฐานข้อมูลซึ่ง (AFAIK) ไม่สนับสนุนตัวเลขที่เพิ่มขึ้นอัตโนมัติเช่นฐานข้อมูลส่วนบุคคลทางภูมิศาสตร์