एक MySQL डेटाबेस में 60 बूलियन स्टोर कैसे करें?

Question

मैं एक मोबाइल ऐप बना रहा हूं, मैं PHP & MySQL का बैकएंड लिखने के लिए उपयोग करता हूं - REST API।

यदि मुझे अपने मोबाइल ऐप में "रिपोर्ट्स" (उपयोगकर्ताओं को किसी रूप में चीजों की जांच करनी है) नामक तालिका में लगभग 50-60 बूलियन मानों को स्टोर करना है, तो मैं एक सरल सरणी में मान (0/1) संग्रहीत करता हूं। मेरी MySQL तालिका में क्या मुझे प्रत्येक बूलियन मान के लिए एक अलग कॉलम बनाना चाहिए या यह पर्याप्त है यदि मैं केवल "110101110110111 ..." जैसे "नंबर" के रूप में स्टोर करने के लिए स्ट्रिंग या इंट का उपयोग करता हूं?

मुझे डेटा जेएसओएन के साथ मिलता है और डालता है।

अद्यतन 1: मुझे बस इतना करना है कि सब कुछ 1 है, अगर उनमें से एक 0 है तो यह एक "समस्या" है। 2 वर्षों में इस तालिका में लगभग 15.000-20.000 पंक्तियां होंगी, इसे बहुत तेज और अंतरिक्ष-बचत जितना संभव हो सके।

अद्यतन 2: गति के मामले में कौन सा समाधान तेज है? एक अलग स्ट्रिंग/बाइनरी प्रकार में इसे अलग कॉलम बनाम बनाते हैं। अगर मुझे यह जांचना है कि कौन से 0 हैं? क्या यह एक अच्छा समाधान है यदि मैं इसे एक कॉलम में "नंबर" के रूप में संग्रहीत करता हूं और यदि यह "111..111" नहीं है तो उसे मोबाइल ऐप पर JSON के रूप में भेजें जहां मैं मान को पार्स करता हूं और इसे उपयोगकर्ता के डिवाइस पर विश्लेषण करता हूं? मान लें कि मुझे 50 के पंक्तियों से निपटना है।

अग्रिम धन्यवाद।

Answer 1

खोज के समय प्रति मूल्य एक अलग कॉलम अधिक लचीला है।

अलग-अलग पंक्तियों में बूलियन मानों के अलग-अलग संग्रह होने पर एक अलग कुंजी/मान तालिका अधिक लचीली होती है।

और, यदि

1. अपने बूलियन मानों की सूची और अधिक या कम स्थिर
2. सब अपनी पंक्तियों उन सभी बूलियन मान है
3. अपने प्रदर्शन के लिए महत्वपूर्ण खोज पंक्तियों को मिल रहा है, जिसमें किसी भी मान झूठी

फिर '1001010010' जैसे टेक्स्ट स्ट्रिंग का उपयोग करके उन्हें स्टोर करने का एक अच्छा तरीका है। आप इस

WHERE flags <> '11111111' 

जैसे पंक्तियों को ढूंढने के लिए खोज सकते हैं।

आप एक बिट प्रति ध्वज के साथ एक बिनरी कॉलम का उपयोग कर सकते हैं। लेकिन यदि आप पाठ का उपयोग करते हैं तो आपकी तालिका आकस्मिक प्रश्नों और आंखों के निरीक्षण के लिए उपयोग करना आसान हो जाएगी। जब तक आप कई लाख पंक्तियों को संग्रहित करना शुरू नहीं करते हैं, तब तक CHAR के बजाय BINARY का उपयोग करने से स्थान बचत महत्वपूर्ण नहीं होगी।

संपादित करें यह कहा जाना चाहिए: हर बार जब मैंने बूलियन विशेषताओं के सरणी के साथ ऐसा कुछ बनाया है, तो मैं बाद में निराश हो गया कि यह कितना लचीला हुआ। उदाहरण के लिए, मान लें कि यह प्रकाश बल्बों की एक सूची थी। सहस्राब्दी के मोड़ पर, बूलियन झंडे की तरह

screw base 
halogen 
mercury vapor 
low voltage 

फिर, चीजों को बदल सकते हैं और मैं अपने आप को और अधिक बूलियन झंडे की आवश्यकता होगी, की तरह लगता है,

LED 
CFL 
dimmable 
Energy Star 

आदि

अचानक सामान गया हो सकता है मेरे डेटा प्रकारों को पकड़ने के लिए पर्याप्त नहीं है जो मुझे पकड़ने की आवश्यकता है।जब मैंने लिखा "आपकी बूलियन मानों की सूची अधिक या कम स्थिर है" मेरा मतलब था कि आप उचित रूप से अपने आवेदन के जीवनकाल में प्रकाश-बल्ब विशेषताओं की तरह कुछ नहीं होने की अपेक्षा करते हैं।

तो, गुणों की एक अलग तालिका एक बेहतर समाधान हो सकता है। इसमें ये कॉलम होंगे:

item_id   fk to item table   -- pk 
    attribute_id  attribute identifier  -- pk 
    attribute_value 

यह अंततः लचीला है। आप बस नए झंडे जोड़ सकते हैं। आप उन्हें अपने आवेदन के जीवनकाल में किसी भी समय मौजूदा आइटम, या नए आइटम में जोड़ सकते हैं। और, हर आइटम को झंडे के समान संग्रह की आवश्यकता नहीं होती है। आप "क्या वस्तुओं में कोई झूठी विशेषता है?" लिख सकते हैं इस तरह क्वेरी:

SELECT DISTINCT item_id FROM attribute_table WHERE attribute_value = 0 

लेकिन, आप सावधान रहना होगा क्योंकि क्वेरी "क्या आइटम अनुपलब्ध गुण" एक बहुत कठिन लिखने के लिए है।

Answer 2

आपके विशिष्ट उद्देश्य के लिए, जब कोई शून्य-ध्वज एक प्रोबलेन (अपवाद) होता है और अधिकांश प्रविष्टियां (जैसे 99%) "1111 ... 1111" होंगी, तो मुझे उन सभी को स्टोर करने का कोई कारण नहीं दिखाई देगा। मैं एक अलग टेबल तैयार करूंगा जो केवल अनचेक झंडे को स्टोर करता है। तालिका इस तरह दिख सकती है: uncheked_flags (user_id, flag_id)। एक अन्य तालिका में आप अपनी ध्वज परिभाषाओं को संग्रहीत करते हैं: झंडे (flag_id, flag_name, flag_description)।

तब आपकी रिपोर्ट SELECT * FROM unchecked_flags जितनी सरल है।

अद्यतन - संभव तालिका परिभाषाएँ:

CREATE TABLE `flags` (
    `flag_id` TINYINT(3) UNSIGNED NOT NULL AUTO_INCREMENT, 
    `flag_name` VARCHAR(63) NOT NULL, 
    `flag_description` TEXT NOT NULL, 
    PRIMARY KEY (`flag_id`), 
    UNIQUE INDEX `flag_name` (`flag_name`) 
) ENGINE=InnoDB; 

CREATE TABLE `uncheked_flags` (
    `user_id` MEDIUMINT(8) UNSIGNED NOT NULL, 
    `flag_id` TINYINT(3) UNSIGNED NOT NULL, 
    PRIMARY KEY (`user_id`, `flag_id`), 
    INDEX `flag_id` (`flag_id`), 
    CONSTRAINT `FK_uncheked_flags_flags` FOREIGN KEY (`flag_id`) REFERENCES `flags` (`flag_id`), 
    CONSTRAINT `FK_uncheked_flags_users` FOREIGN KEY (`user_id`) REFERENCES `users` (`user_id`) 
) ENGINE=InnoDB; 

Answer 3

आप , समर्पित स्तंभों का उपयोग प्रत्येक बूलियन के लिए से बाहर एक बेहतर खोज मिल सकता है, लेकिन प्रमुखता गरीब है और यहां तक ​​कि आप सूचकांक प्रत्येक अगर कॉलम में यह ट्रैवर्सल या स्कैनिंग का एक उचित हिस्सा शामिल होगा।

यदि आप केवल उच्च-मूल्य 0xFFF की तलाश में हैं .... तो निश्चित रूप से बिटमैप, यह आपकी कार्डिनालिटी समस्या (प्रति ओपी अपडेट) हल करता है। ऐसा नहीं है कि आप समानता की जांच कर रहे हैं ... हालांकि यह सामान्य है और यदि यह सामान्य है तो पेड़ को उच्च-मूल्यों में भारी गिरा दिया जाएगा और आवेषण पर नोड को विभाजित करने के लिए एक गर्म स्थान बना सकता है।

बिट मैपिंग और बिटवाई ऑपरेटर मास्क का उपयोग करके अंतरिक्ष को बचाया जाएगा, लेकिन एक बाइट से गठबंधन करने की आवश्यकता होगी, इसलिए एक अप्रयुक्त "टिप" (शायद भविष्य के क्षेत्रों के लिए प्रावधान) हो सकता है, इसलिए मुखौटा एक रखरखाव की लंबाई या क्षेत्र 1 एस के साथ गद्दीदार।

यह आपके आर्किटेक्चर में जटिलता भी जोड़ देगा, जिसके लिए bespoke कोडिंग, bespoke मानकों की आवश्यकता हो सकती है।

आपको किसी भी खोज के महत्व पर एक विश्लेषण करने की आवश्यकता है (आप आमतौर पर सभी को खोजने की उम्मीद नहीं कर सकते हैं या यहां तक ​​कि किसी भी असतत फ़ील्ड)।

यह डेटा को denormalising के लिए और विशिष्ट ग्राहकों के लिए सेवा अनुरोध ट्यूनिंग के लिए एक बहुत ही आम रणनीति है। (जहां कुछ रिपॉन्स एक ही लेनदेन के लिए दूसरों की तुलना में फैटर होते हैं)।