यह एक मुख्य गलतफहमी . पर आधारित है Postgres और EAV डिज़ाइन की आंतरिक कार्यप्रणाली के बारे में ।
यदि आपके पास सैकड़ों अलग-अलग फ़ील्ड या विशेषता प्रकारों का डायनामिक सेट नहीं है, तो सभी स्तंभों वाली एकल तालिका का उपयोग करें - डेटाबेस सामान्यीकरण
को छोड़कर . बिना मान वाले कॉलम NULL . से भरे हुए हैं .
शून्य संग्रहण बहुत सस्ता है , 1 बिट . पर कब्जा कर रहा है नल बिटमैप के लिए तालिका में प्रति कॉलम, आमतौर पर 64 कॉलम को कवर करने के लिए 8 बाइट्स की इकाइयों में आवंटित किया जाता है। देखें:
- पोस्टग्रेस्क्ल डीबी का उपयोग करके एक NULL मान को स्टोर करने के लिए कितने डिस्क-स्पेस की आवश्यकता है?
एकल . के लिए एक अलग पंक्ति अतिरिक्त विशेषता कम से कम में रहती है एक अतिरिक्त 36 बाइट्स ।
4 bytes item identifier 23 bytes heap tuple header 1 byte padding 8 bytes minimum row data size
आमतौर पर अधिक, पैडिंग और अतिरिक्त ओवरहेड के कारण।
इस तरह के एक बोझिल ईएवी डिज़ाइन का भुगतान करने से पहले सैकड़ों अलग-अलग, कम आबादी वाले कॉलम होने चाहिए - और hstore
या jsonb
Postgres 9.4 में कि . के लिए बेहतर समाधान होगा . आपके डिज़ाइन और अगर . के बीच में शायद ही कोई जगह हो वहाँ था, आप शायद एक enum
प्रकार के लिए।
साथ ही, प्रश्न अधिक जटिल और महंगे हैं। हम यहां एक तंग जगह पर हैं।
इसके बजाय इस तरह के टेबल लेआउट का उपयोग करें:
CREATE TABLE users (
users_id serial PRIMARY KEY
, salutation text
, given_name text
, surname text
, alias text
... (many) more columns
);
CREATE TABLE address (
address_id serial PRIMARY KEY
, users_id int REFERENCES users
, city text -- or separate TABLE city incl region_id etc. ...
, region_id int REFERENCES region
, address text
... (many) more columns
);
अधिक सलाह के साथ निकट से संबंधित उत्तर:
