ฉันจะจัดการตารางที่มีตัวแปร 256+ ตัวได้อย่างไร


10

ฉันทำงานกับข้อมูลสำมะโนประชากรและดาวน์โหลดไฟล์ CSV หลายไฟล์แต่ละไฟล์มีคอลัมน์ / ตัวแปร 600ish ฉันต้องการเก็บไว้ในฐานข้อมูลที่สามารถสืบค้นได้ แต่ทุกอย่างที่ฉันพยายาม (MS Access, Arc Geodatabase table) ตัดตารางเป็น 256 คอลัมน์ มีวิธีแก้ไขปัญหาสำหรับการจัดการตารางขนาดใหญ่ที่เข้าถึงได้โดยคนที่ไม่ใช่ DBA หรือไม่?


2
ด้วยจำนวนฐานข้อมูลมาตรฐานใด ๆ ฉันสงสัยว่าตารางขนาดใหญ่เหล่านี้ควรถูกแยกออกเป็นหลายตาราง (หรือหลาย ๆ ) ที่เล็กกว่าที่เกี่ยวข้องกับหน่วยสำรวจสำมะโนประชากรของพวกเขา
รอย

คำตอบ:


7

PostgreSQL มีข้อ จำกัด คอลัมน์ระหว่าง 250 ถึง 1600 "ขึ้นอยู่กับประเภทคอลัมน์" และสนับสนุนข้อมูลเชิงพื้นที่และแบบสอบถามด้วยส่วนขยาย PostGIS ดังนั้นฉันอยากจะทำสองสิ่ง:

ขั้นแรกให้คอลัมน์แสดงหมวดหมู่แทนข้อความอิสระสร้างตารางแยกต่างหากด้วยหมวดหมู่เหล่านั้นและแทนที่คอลัมน์ด้วย ID จำนวนเต็มและข้อ จำกัด คีย์ต่างประเทศอ้างอิงตารางหมวดหมู่

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

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

การสนับสนุนเชิงพื้นที่นั้นไม่ดีสำหรับฐานข้อมูล bigtable ประเภทนี้ แต่ MongoDB รองรับการสืบค้นเชิงพื้นที่และข้อมูล 2D และ CouchDB ดูเหมือนจะมีฟังก์ชั่นที่คล้ายกัน


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

@MerseyViking, เขา (@scoball) จะแยกตารางหรือดำเนินการอื่น ๆ ที่กล่าวถึงได้อย่างไรถ้าเขาไม่สามารถนำเข้าข้อมูลไปยังโปรแกรมใด ๆ ที่จัดการตารางได้? ข้อมูลอยู่ในรูปแบบ CSV
ปาโบล

2
@Pablo ฉันคิดว่าคุณไม่ยุติธรรมกับ MerseyViking: ถ้าคุณได้รับอนุญาตให้เขียนสคริปต์เพื่อนำเข้าตาราง - ซึ่งคุณต้องถูกบังคับให้นำโซลูชันของคุณไปใช้ - แล้วเขาก็ไม่มีปัญหา ในการเขียนหนึ่งที่สมบูรณ์โดยทั่วไปและมีความยืดหยุ่น (ฉันรู้สิ่งนี้จากประสบการณ์เพราะฉันได้ทำเพื่อฐานข้อมูลการสำรวจสำมะโนประชากรที่มีขนาดใหญ่มาก) นอกจากนี้เขาแนะนำตัวเลือกมากมายที่ทำงานเกี่ยวกับข้อ จำกัด ของเขตข้อมูล 256
whuber

"ที่คอลัมน์แสดงถึงหมวดหมู่แทนที่จะเป็นข้อความอิสระ" คุณต้องแมปคอลัมน์เหล่านั้นด้วยตนเอง
ปาโบล

2
@Pablo เท่านั้นหากคุณใช้ซอฟต์แวร์ไม่เพียงพอ :-) เวิร์กโฟลว์ในวรรค 2-3 สามารถทำได้ด้วยคำสั่งเพียงไม่กี่คำโดยใช้เกือบทุกโปรแกรมทางสถิติที่ทันสมัยเช่น (แน่นอนฉันไม่สนับสนุนการใช้โปรแกรมดังกล่าวแทนฐานข้อมูลฉันแค่ชี้ให้เห็นว่าด้วยชุดเครื่องมือที่เหมาะสมทุกอย่างในคำตอบนี้สามารถทำได้อย่างง่ายดายและมีประสิทธิภาพ)
whuber

7

ฉันเพิ่งจัดการกับปัญหาเดียวกันกับไฟล์ CSV โปรไฟล์การสำรวจสำมะโนประชากรแคนาดาสถิติที่มี 2172 คอลัมน์ คุณสามารถนำเข้า csv ของคุณไปยัง ESRI File Geodatabase (FGDB) หากคุณมีสิทธิ์เข้าถึง ArcGIS ตามที่ ESRI, รูปแบบ FGDB สามารถจัดการ 65,534 สาขาในชั้นเรียนหรือที่โต๊ะ

ในกรณีของฉันฉันสามารถนำเข้าไฟล์ CSV แบบกว้างคอลัมน์ 2172 ของฉันลงในตาราง FGDB ได้โดยไม่มีปัญหาใด ๆ

เมื่อคุณนำตารางทั้งหมดมาไว้ใน FGDB คุณสามารถแบ่งส่วนต่างๆตามที่คุณต้องการ (เช่นมีเหตุผลหรือตามข้อ จำกัด ของ db) ตรวจสอบให้แน่ใจว่าคุณเก็บคอลัมน์ id ที่ไม่ซ้ำกันเพื่อให้แน่ใจว่าคุณสามารถรวมเข้าด้วยกันเป็น จำเป็น


1
! ที่น่าสนใจ ฉันพยายามนำเข้าจาก csv ไปยังไฟล์ geodatabase เมื่อฉันตั้งค่าฉันดูรายการตัวแปรที่มันจะนำเข้าและจะหยุดรายการพวกเขาหลังจาก 256 ตัวแปรดังนั้นฉันไม่ได้ดำเนินการต่อ ฉันจะดูอีกครั้ง
scoball

2
ลองดูลิงค์นี้: assets.nhgis.org/How_to_Import_256_Columns_GIS.pdf
Brent Edwards

ฐานข้อมูลไฟล์ Geod มีข้อ จำกัด สูงดังนั้นจึงเป็นไปได้ว่ามีบางสิ่งเกิดขึ้นในการนำเข้า
nicksan

2

สั้น:
ตัวเลือกของฉันสำหรับข้อมูลที่มีแอตทริบิวต์จำนวนมากหรือชนิดตัวแปรตัวแปรสำหรับแต่ละวัตถุคือการใช้โมเดลข้อมูล KEY / VALUE สามารถนำไปใช้และทำงานได้ดีใน sql (ฉันอยากจะแนะนำ postgresql + postgis)

คำอธิบาย:
1) คุณมีตารางหนึ่งตารางสำหรับคุณลักษณะสมมติว่ามีจุด ตารางนี้มี ID และ GEOMETRY สำหรับแต่ละจุด

2) คุณมีอีกหนึ่งตารางสำหรับ 'แอตทริบิวต์' ซึ่งเป็นคู่ของคีย์ / ค่า ตารางนี้มี ID คอลัมน์, POINT_ID (FK), KEY (varchar), VALUE (varchar)

ตอนนี้แต่ละจุดสามารถมีคุณสมบัติที่ไม่มีที่สิ้นสุดที่จัดเก็บเช่นนี้

ID   POINT_ID   KEY   VALUE
1        1      type     burger shop
2        1      name     SuperBurger
3        1      address  123, a ST.

OpenStreetMaps ทำงานเช่นนั้นและได้ผลดีมากดูที่นี่และที่นี่

เพื่อนำเข้าข้อมูลฉันจะเขียนสคริปต์ไพ ธ อน


สิ่งนี้มักเรียกว่ารูปแบบ "ยาว" ของข้อมูลและเป็นสิ่งที่ควรรู้ แม้ว่ามันจะโอเคสำหรับที่เก็บข้อมูลที่ยืดหยุ่น แต่ก็ไม่มีประโยชน์สำหรับการวิเคราะห์หลายตัวแปร (ซึ่งจะเป็นการวิเคราะห์เปรียบเทียบคุณลักษณะสองอย่างหรือมากกว่า)
whuber

@ โฮเบอร์มันไม่ไร้ประโยชน์สำหรับการวิเคราะห์หลายตัวแปร แต่แน่นอนว่าคุณต้องมีซอฟต์แวร์ที่มีโครงสร้างหรือทักษะการเขียนโปรแกรมที่ดี ที่นี่ฉันใช้การรวมกันของ postgis + django (python web framework) เพื่อทำงานข้อมูลของดิน (ph, al, clay, ฯลฯ ) เมื่อฉันต้องการฉันจะใส่ข้อความที่ตัดตอนมาลงในตารางก่อนการประมวลผล รุ่นนี้ถูกเลือกเพราะโครงสร้างเดียวกันจะประมวลผลข้อมูลที่ตรงต่อเวลาโดยพลการอื่น ๆ
ปาโบล

ยุติธรรมเพียงพอ: ฉันควรจะพูดว่า "ไร้ประโยชน์เหมือนที่เป็นอยู่" ให้ข้อมูลทั้งหมดจะถูกเก็บไว้ - และ - คุณสามารถประมวลผลข้อมูลในรูปแบบใดก็ได้ที่คุณต้องการ การประมวลผลค่อนข้างง่ายโดยใช้วิธีการของ @ MerseyViking เมื่อเปรียบเทียบกับวิธีการคีย์ / ค่า นอกจากนี้เมื่อได้รับตารางจริงๆขนาดใหญ่ที่เราจะเริ่มได้รับความกังวลเกี่ยวกับขนาดรวม ความซ้ำซ้อนในการจัดเก็บคีย์ / ค่านั้นยอดเยี่ยมจนแทบจะไม่ใช้สำหรับการวิเคราะห์ชุดข้อมูลที่มีขนาดใหญ่มาก (ฉันไม่สามารถพูดกับความถี่ของการใช้เพื่อการเก็บข้อมูลได้อย่างหมดจด)
whuber

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

ดูเหมือนว่าวิธีแก้ปัญหาของคุณจะทำให้โปรแกรมซับซ้อนเหมือนการเขียนโปรแกรมซึ่งจำเป็นต้องมี "ทักษะการเขียนโปรแกรมที่ดี" ฉันสนับสนุนการเก็บข้อมูลในรูปแบบที่มีประสิทธิภาพมากที่สุดสำหรับ RDBMS เช่น PostgreSQL นอกจากนี้ดูเหมือนว่าจะเป็นจุดที่สงสัยเนื่องจากคำตอบของเบรนต์แสดงให้เห็นว่าการ จำกัด วงเงิน 256 คอลัมน์นั้นเป็นการหลอกลวง
MerseyViking
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.