सामान्य MySQL फ़ील्ड्स और उनके उपयुक्त डेटा प्रकार

Question

मैं एक बहुत छोटा MySQL डेटाबेस स्थापित कर रहा हूं जो पहले क्षेत्र के लिए 'सही' डेटाटाइप को खोजने के लिए स्टोर, पहला नाम, अंतिम नाम, ईमेल और फोन नंबर संग्रहीत करता है। मुझे पता है कि एक सही जवाब जैसी कोई चीज नहीं है, लेकिन आम तौर पर इस्तेमाल किए जाने वाले क्षेत्रों जैसे कि इन के लिए किसी प्रकार का आम सम्मेलन होना चाहिए। उदाहरण के लिए, मैंने निर्धारित किया है कि एक अनियंत्रित यूएस फोन नंबर एक अहस्ताक्षरित इंट के रूप में संग्रहीत होने के लिए बहुत बड़ा है, यह कम से कम एक bigint होना चाहिए।

क्योंकि मुझे यकीन है कि अन्य लोग शायद इसे उपयोगी पाएंगे, मैं अपने सवाल को सिर्फ उन क्षेत्रों तक सीमित नहीं रखना चाहता, जिनका मैंने ऊपर उल्लेख किया है।

सामान्य डेटाबेस फ़ील्ड के लिए क्या डेटाटाइप्स उपयुक्त हैं? फ़ोन नंबर, ईमेल और पता जैसे फ़ील्ड?

Answer 1

किसी को इससे बेहतर जवाब पोस्ट करने जा रहा है, लेकिन सिर्फ यह बात है कि व्यक्तिगत रूप से मैं किसी भी तरह के पूर्णांक क्षेत्र में फोन नंबर स्टोर नहीं करना चाहता था, मुख्यतः:

1. आपको इसके साथ किसी भी प्रकार के अंकगणित करने की आवश्यकता नहीं है, और
2. जल्दी या बाद में किसी के पास (कुछ ऐसा करने की कोशिश करने वाला) अपने क्षेत्र कोड के आसपास कोष्ठक रखे।

सामान्य तौर पर, मैं लगभग विशेष रूप से उपयोग करने के लिए लगता है:

• INT (11) किसी भी चीज के लिए जो कि एक आईडी है या दूसरी आईडी का संदर्भ देती है
• समय टिकटों के लिए DATETIME
• 255 वर्णों (पृष्ठ शीर्षक, नाम, आदि) के अंतर्गत होने वाली गारंटी के लिए VARCHAR (255)
• बहुत ज्यादा सब कुछ के लिए पाठ।

बेशक अपवाद हैं, लेकिन मुझे लगता है कि अधिकांश घटनाओं को कवर करता है।

Comments

इसके अलावा, पूर्णांक केवल 2 बिलियन के मूल्य तक का समर्थन करते हैं। वह 2,000,000,000 है। जब आप देश कोड के साथ अंतरराष्ट्रीय फोन नंबर स्टोर करना चाहते हैं तो वास्तव में पर्याप्त जगह नहीं है। मैं भी कैसे आप 655-405-4055 तरह एक नंबर स्टोर करने के लिए पर्याप्त स्थान मिल सकता है देख पा रहे हैं नहीं (+६५५४०५४०५५)

— Kibbee

इसके अलावा यह सिर्फ गलत है। मुझसे ज्यादा समझदार किसी ने मुझे बताया कि जब मैं शुरू कर रहा था (डेटाबासिंग के साथ) सिर्फ इसलिए कि कुछ ऐसा दिखता है जैसे नंबर का मतलब यह नहीं है या इसे ऐसे ही माना जाना चाहिए ...

— da5id

नेत्रहीन varchar (255) का उपयोग करना एक बुरा विचार है। कम से कम लंबाई का अनुमान लगाने के लिए कुछ बुनियादी प्रयास लागू करें।

— मॉर्गन टॉकर

@ मॉर्गन टॉकर: यह सबसे अच्छा अभ्यास है, 255 वर्णों से नीचे की कोई भी चीज समान स्थान लेगी।

— 13

@ रेवेन: यह स्टोरेज इंजन विशिष्ट है - और स्टोरेज केवल लागत नहीं है। डेटा और अस्थायी तालिकाओं (मेमोरी इंजन) को सॉर्ट करना निश्चित राशि का उपयोग करेगा।

— मॉर्गन टॉकर

Answer 2

यहां कुछ सामान्य डेटाटिप्स हैं जिनका मैं उपयोग करता हूं (हालांकि मैं बहुत समर्थक नहीं हूं):

| Column           | Data type     | Note
| ---------------- | ------------- | -------------------------------------
| id               | INTEGER       | AUTO_INCREMENT, UNSIGNED                                                          |  
| uuid             | CHAR(36)      | or CHAR(16) binary                                                                |  
| title            | VARCHAR(255)  |                                                                                   |  
| full name        | VARCHAR(70)   |                                                                                   |  
| gender           | TINYINT       | UNSIGNED                                                                          |  
| description      | TINYTEXT      | often may not be enough, use TEXT 
                                     instead          
| post body        | TEXT          |                                                                                   |  
| email            | VARCHAR(255)  |                                                                                   |  
| url              | VARCHAR(2083) | MySQL version < 5.0.3 - use TEXT                                                  |  
| salt             | CHAR(x)       | randomly generated string, usually of 
                                     fixed length (x)    
| digest (md5)     | CHAR(32)      |                                                                                   |  
| phone number     | VARCHAR(20)   |                                                                                   |  
| US zip code      | CHAR(5)       | Use CHAR(10) if you store extended 
                                     codes      
| US/Canada p.code | CHAR(6)       |                                                                                   |  
| file path        | VARCHAR(255)  |                                                                                   |  
| 5-star rating    | DECIMAL(3,2)  | UNSIGNED                                                                          |  
| price            | DECIMAL(10,2) | UNSIGNED                                                                          |  
| date (creation)  | DATE/DATETIME | usually displayed as initial date of 
                                     a post                                       |  
| date (tracking)  | TIMESTAMP     | can be used for tracking changes in a 
                                     post                                        |  
| tags, categories | TINYTEXT      | comma separated values *                                                          |  
| status           | TINYINT(1)    | 1 – published, 0 – unpublished, … You 
                                     can also use ENUM for human-readable 
                                     values
| json data        | JSON          | or LONGTEXT       

Comments

@yentsun - ईमेल वास्तव में केवल 254 हैं; नील

— मैक्गिवेन

Answer 3

मेरे अनुभव में, पहले नाम / अंतिम नाम फ़ील्ड में कम से कम 48 अक्षर होने चाहिए - कुछ देशों जैसे मलेशिया या भारत के नाम हैं जो अपने पूर्ण रूप में बहुत लंबे हैं।

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

MySQL में आप इस प्रकार की जानकारी के लिए VARCHAR फ़ील्ड का उपयोग कर सकते हैं। जब भी यह आलसी लगता है, इसका मतलब है कि आपको सही न्यूनतम आकार के बारे में बहुत चिंतित होने की आवश्यकता नहीं है।

Comments

पोस्टल कोड पर अपनी टिप्पणी का समर्थन करने के लिए, यूके या कनाडा जैसे देशों में, पोस्टल कोड अल्फ़ान्यूमेरिक हैं।

— एंडी बेयर्ड

आपको सही न्यूनतम आकार stackoverflow.com/questions/262238/… के

— रोहित बंगा

@iamrohitbanga आप अच्छी तरह से परिभाषित डेटा के लिए सही हैं, नामों के लिए VARCHAR(255)समझ में आता है।

— स्टेटिक्सन

Answer 4

चूंकि आप एक चर लंबाई (नाम, ईमेल पते) के डेटा के साथ काम करने जा रहे हैं, तो आप VARCHAR का उपयोग करना चाहते हैं। VARCHAR क्षेत्र द्वारा उठाए गए स्थान की मात्रा [field length]अधिकतम लंबाई 255 तक + 1 बाइट्स है, इसलिए मैं एक सही आकार खोजने की कोशिश करने के बारे में बहुत अधिक चिंता नहीं करूंगा। एक नज़र डालें जो आप कल्पना करेंगे कि सबसे लंबी लंबाई हो सकती है, फिर इसे दोगुना करें और इसे अपने वाराहार की सीमा के रूप में सेट करें। ने कहा कि...:

मैं आम तौर पर VARCHAR (100) होने के लिए ईमेल फ़ील्ड सेट करता हूं - मैं अभी तक इस समस्या से नहीं आया हूं। नाम I VARCHAR (50) में सेट करें।

जैसा कि दूसरों ने कहा है, फोन नंबर और ज़िप / पोस्टल कोड वास्तव में संख्यात्मक मूल्य नहीं हैं, वे अंक 0-9 (और कभी-कभी अधिक!) वाले तार हैं, और इसलिए आपको उन्हें एक स्ट्रिंग के रूप में मानना ​​चाहिए। VARCHAR (20) अच्छी तरह से पर्याप्त होना चाहिए।

ध्यान दें कि यदि आप फोन नंबर को पूर्णांक के रूप में संग्रहीत करते हैं, तो कई सिस्टम यह मानेंगे कि 0 से शुरू होने वाली संख्या एक अष्टक (आधार 8) संख्या है! इसलिए, पूरी तरह से मान्य फोन नंबर "0731602412" दशमलव संख्या "124192010" के रूप में आपके डेटाबेस में डाल दिया जाएगा !!

Answer 5

मैं उसी चीज के बारे में कर रहा हूं, और यहां मैंने जो किया है।

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

NameID कॉलम सभी तालिकाओं में एक छोटा सा हो जाता है क्योंकि मैं काफी निश्चित हूं कि मैं 32000 से अधिक प्रविष्टियां नहीं करूंगा। लगभग सब कुछ varchar (n) से लेकर 20 से 200 तक है, यह इस बात पर निर्भर करता है कि आप क्या स्टोर करना चाहते हैं (जन्मदिन, टिप्पणियाँ, ईमेल, वास्तव में लंबे नाम)। यह वास्तव में इस बात पर निर्भर है कि आप किस तरह का सामान स्टोर कर रहे हैं।

संख्या तालिका वह है जहाँ से मैं विचलित करता हूँ। मैंने इसका नाम NameID, Phone #, CountryCode, Extension और PhoneType लेबल वाले पांच कॉलम रखे हैं। मैंने पहले से ही NameID पर चर्चा की। फोन # varchar (12) है जिसमें एक चेक बाधा कुछ इस तरह दिख रही है: CHECK (फोन # जैसे '[0-9] [0-9] [0-9] - [0-9] [0-9] [0 -9] - [0-9] [0-9] [0-9] [0-9] ')। यह सुनिश्चित करता है कि केवल वही जो मैं चाहता हूं वह डेटाबेस में बनाता है और डेटा बहुत सुसंगत रहता है। विस्तार और देश कोड मैं अशक्त छोटे निशान कहा जाता है, लेकिन अगर आप चाहते थे तो वेचर हो सकते हैं। PhoneType varchar (20) है और अशक्त नहीं है।

उम्मीद है की यह मदद करेगा!