การออกแบบฐานข้อมูลที่ดีนั้นมีความสำคัญน้อยกว่าสำหรับฐานข้อมูลเชิงพื้นที่หรือไม่?

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

ด้วยซอฟต์แวร์ที่ต้องใช้โชคและฐานข้อมูลที่มีมากกว่า 100 ตารางในตารางฉันต้องถาม:

มีเหตุผลที่ดีสำหรับการพิจารณาอื่นนอกเหนือจากการทำให้เป็นมาตรฐานเมื่อออกแบบฐานข้อมูลเชิงพื้นที่หรือไม่?

ฉันเดาว่าผู้คนจะขอตัวอย่าง แต่ฉันไม่สามารถให้ที่นี่ได้ดังนั้นคำถามของฉันอาจมีจุดมุ่งหมายมากกว่าสำหรับผู้ที่หมายความว่า 100 สาขาไม่มีปัญหาและง่ายต่อการบำรุงรักษามากกว่าการออกแบบตามปกติที่เหมาะสม

อะไรคือข้อโต้แย้ง?

ฉันรู้สึกว่าฐานข้อมูลเชิงพื้นที่ควรได้รับการปฏิบัติไม่แตกต่างจากฐานข้อมูลดั้งเดิม พวกเขากำลังทำสิ่งเดียวกันโดยจัดเก็บข้อมูลจำนวนมากเพื่อการดึงข้อมูลที่รวดเร็ว ตัวอย่างเช่นใน PostgreSQL / PostGIS รูปทรงเรขาคณิตเป็นเพียงประเภทข้อมูลอื่น เช่นเดียวกับข้อความหรือจำนวนเต็ม เหมือนกันใน SQL Server 2008 เหมือนกันใน Oracle หากส่วน "อวกาศ" เป็นเพียงส่วนหนึ่งของประเภทข้อมูลในฐานข้อมูลแล้วมันแตกต่างจากฐานข้อมูลต้นฉบับจริงหรือไม่? นี่หมายความว่าเราควรทิ้งกฎทั้งหมดของการออกแบบฐานข้อมูลแบบดั้งเดิมหรือไม่?

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

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

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

คำถามเหล่านี้ทั้งหมดใช้กับฐานข้อมูลดั้งเดิมและฐานข้อมูลเชิงพื้นที่ หากคุณไปที่http://en.wikipedia.org/wiki/Database_normalizationคุณจะพบว่ามันใช้กับฐานข้อมูลเชิงพื้นที่ด้วย

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

ดังนั้นฉันคิดว่าคำตอบสั้น ๆ คือในความคิดของฉันการออกแบบฐานข้อมูลมีความสำคัญกับฐานข้อมูลเชิงพื้นที่เหมือนกับฐานข้อมูลดั้งเดิม

ฉันเห็นสิ่งนี้มาก ฉันรู้สึกว่ามันเกิดขึ้นจากความจริงที่ว่าคน GIS นั้นมาจากการสำรวจภูมิหลังและไม่มีภูมิหลัง / ความเข้าใจในฐานข้อมูล ฉันเห็นการเปลี่ยนแปลงนี้เนื่องจากมีองค์กรจำนวนมากย้ายโครงสร้างพื้นฐาน GIS มาอยู่ในกลุ่มไอที

GIS Software Legacy

ค่าใช้จ่ายสูงก่อนหน้าของ ArcSDE และการขาดประเภทข้อมูลเชิงพื้นที่ใน SQL Server (จนถึงปี 2008) และ Oracle จนถึงรุ่น 10 หมายความว่ามีทางเลือกน้อย แต่เพื่อเก็บข้อมูลในรูปแบบไฟล์สำหรับหลายองค์กร (และโดยผู้ประมูลเพื่อลดต้นทุนการเสนอราคา) .

การแนะนำประเภทเชิงพื้นที่ดั้งเดิมใน SQL Server นั้นหมายถึงเกือบจะในทันทีที่ ArcSDE เริ่มต้นจากการลงทุนขนาดใหญ่เพื่อที่จะรวมอยู่ใน ArcGIS ฟรีและ "นำไปสู่การพับ" ของข้อมูลเชิงพื้นที่ในองค์กร

องค์กรที่ใช้ ArcGIS และ SQL Server ก่อนหน้านี้มีสามตัวเลือก:

1. จ่ายค่าธรรมเนียม 20k + เพื่อซื้อ ArcSDE และจัดเก็บข้อมูลเชิงพื้นที่ในฐานข้อมูลเซิร์ฟเวอร์ SQL ที่ "เหมาะสม"
2. จัดเก็บข้อมูลเชิงพื้นที่ใน shapefiles / GDB ส่วนบุคคลและเชื่อมโยงไปยังส่วนที่เหลือของข้อมูลองค์กรในฐานข้อมูล (หรือส่งออกแอตทริบิวต์เหล่านี้ไปยัง DBFs)
3. สลับผู้ขาย GIS และจัดเก็บข้อมูลเชิงพื้นที่ในฐานข้อมูลเดียว แต่ในรูปแบบที่สามารถเข้าถึงได้โดยซอฟต์แวร์ GIS ใหม่เท่านั้น

เมื่อ SQL Server มีชนิดของพื้นที่ดั้งเดิมที่ผู้ขายส่วนใหญ่ใช้สิ่งนี้แทนรูปแบบที่เป็นกรรมสิทธิ์ของพวกเขาหมายถึงข้อมูลเชิงพื้นที่สามารถเข้าถึงได้ทันทีโดยโปรแกรมประยุกต์อื่น ESRI จะต้องลดค่าใช้จ่ายของ ArcSDE (ซึ่งรวมอยู่ใน ArcGIS) และ / หรืออนุญาตให้จัดเก็บข้อมูลเชิงพื้นที่ในรูปแบบฐานข้อมูลเนทิฟ

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

เหตุผลขององค์กร

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

เหตุผลด้านต้นทุน

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

ด้วยตาราง 100 คอลัมน์ฉันถือว่าคุณหมายถึงชนิดของเอาต์พุตที่คุณได้รับจากการสร้างการซ้อนทับ "การครอบคลุมหลัก" ของอินพุตหลายอินพุต ใช่สิ่งเหล่านี้เป็นสิ่งประดิษฐ์ของเวิร์กโฟลว์ Arc / INFO แต่ในการป้องกันคุณยังสามารถคิดว่าพวกเขาเป็นจงใจ de-ปกติตารางสำหรับOLAP เนื่องจากมีการใช้งานเป็นส่วนใหญ่สำหรับการประมวลผลการค้นหาไม่ใช่เพื่อการปรับปรุงข้อมูล เหมือนสคีมาของดาวแต่ไม่มีเอ่อจุด โอเคชาอ่อน ๆ แต่ฉันก็ยังคิดว่ามีบางอย่างอยู่ที่นั่น

ใช่ถ้าเริ่มการออกแบบโครงการ GI ใหม่เป็นสิ่งสำคัญและสามารถประหยัดเวลา = เงินในอนาคต http://www.amazon.com/Spatial-Database-Systems-Implementation-Management/dp/1402053916เป็นภาพรวมที่ดีว่าทำไมจึงมีความสำคัญ