2012-12-22 20 views
7

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

मेरे पास एक अद्वितीय ऑटो वृद्धिशील आईडी और एक create_at टाइमस्टैम्प के साथ एक बहुत ही सरल तालिका है।

+-----------+--------------------+ 
| id  |created_at   | 
+-----------+--------------------+ 
| 1   |2012-12-11 20:35:19 | 
| 2   |2012-12-12 20:35:19 | 
| 3   |2012-12-13 20:35:19 | 
| 4   |2012-12-14 20:35:19 | 
+-----------+--------------------+ 

इन स्तंभों के दोनों गतिशील रूप से जोड़ा जाता है (मेरी समस्या का सरलीकृत संस्करण प्रश्न में अवधारणा स्पष्ट करने के लिए) तो यह कहा जा सकता है कि एक नए 'सम्मिलित करें' हमेशा एक अधिक से अधिक आईडी और हमेशा होगा की एक बड़ी तारीख है।

उद्देश्य - बहुत बस आदेश

समाधान एक अवरोही क्रम में परिणाम created_at द्वारा आदेश दिया हड़पने - एक क्वेरी है कि आदेश

SELECT * FROM tablename 
ORDER BY created_at DESC 

समाधान दो अवरोही क्रम में दिनांक के आधार पर आदेश - एक क्वेरी जो अवरोही क्रम में आईडी द्वारा आदेश

SELECT * FROM tablename 
ORDER BY id DESC 

क्या समाधान दो को खराब अभ्यास माना जाता है? या समाधान दो चीजों को करने का सही तरीका है। आपके तर्कों का कोई भी स्पष्टीकरण बहुत उपयोगी होगा क्योंकि मैं अवधारणा को समझने की कोशिश कर रहा हूं, न कि केवल एक उत्तर प्राप्त करें। अग्रिम में धन्यवाद।

+0

ठीक है, आईडी द्वारा सॉर्टिंग इंडेक्सिंग का लाभ उठा सकता है। आपको प्रश्न के लिए अपनी स्कीमा के प्रासंगिक भाग शामिल करना चाहिए। – Perception

+0

जबकि मुझे नहीं पता कि इसके बारे में जाने के लिए 'आधिकारिक तरीका' है, तो 'ऑर्डर बाय' क्वेरी बस ऐसा करने के लिए मौजूद है। कॉलम द्वारा ऑर्डर करने के लिए। मुझे दिखाई देने वाली एकमात्र कमी यह है कि टाइमस्टैम्प में डुप्लीकेट (एक ही सेकेंड में दो आवेषण) हो सकते हैं और यह कि अनुपलब्ध इंडेक्स के कारण क्वेरी धीमी हो सकती है। – ATaylor

उत्तर

6

सामान्य अभ्यास में आप लगभग हमेशा यह मान सकते हैं कि निर्माण आदेश (या तो दिशा) में आपको रिकॉर्ड देने के लिए एक ऑटोइनक्रिकमेंट आईडी को सॉर्ट किया जा सकता है। हालांकि, आपको ध्यान रखना चाहिए कि यह आपके डेटा के संदर्भ में पोर्टेबल नहीं माना जाता है। आप अपने डेटा को किसी अन्य सिस्टम पर ले जा सकते हैं जहां चाबियाँ फिर से बनाई जाती हैं, लेकिन बनाया गया डेटा समान होता है।

वास्तव में इस समस्या का एक बहुत अच्छा StackOverflow discussion है।

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

+0

चर्चा के लिंक के लिए धन्यवाद, बाद में डेटा के साथ क्या हो सकता है, इस पर विचार करने के लिए मेरे शोध –

+2

+1 में इसे याद किया होगा। – Javier

+0

डाउनवोट क्यों?मुझे कम से कम भविष्य के संदर्भ के लिए एक स्पष्टीकरण देखना पसंद है। – davidethell

4

दो विकल्पों के बीच कुछ अंतर हैं।


पहला यह है कि वे अलग-अलग परिणाम दे सकते हैं।

created_at का मान सर्वर पर समायोजित समय से प्रभावित हो सकता है लेकिन id कॉलम अप्रभावित होगा। यदि समय पीछे की ओर समायोजित किया जाता है (या तो मैन्युअल रूप से या स्वचालित रूप से समय सिंक्रनाइज़ेशन सॉफ़्टवेयर द्वारा) तो आप बाद में डाले गए रिकॉर्ड्स प्राप्त कर सकते थे, लेकिन टाइमस्टैम्प के साथ जो पहले डाले गए रिकॉर्ड से पहले थे। इस मामले में आप किस कॉलम द्वारा ऑर्डर करते हैं इसके आधार पर आपको एक अलग ऑर्डर मिलेगा। आप जिस आदेश को "सही" मानते हैं वह आपके ऊपर है।


दूसरा प्रदर्शन है। यह ORDER BY आपके clustered index तक तेज़ी से होने की संभावना है। क्योंकि पंक्ति डेटा एक ही पृष्ठ जहां सूचकांक खोज के लिए सुराग पर है

कैसे क्लस्टर सूचकांक ऊपर प्रश्नों

गति क्लस्टर सूचकांक के माध्यम से एक पंक्ति को एक्सेस करना तेज है।

डिफ़ॉल्ट रूप से क्लस्टर कुंजी प्राथमिक कुंजी है, जो आपके मामले में संभवतः id कॉलम है। आपको शायद पता चलेगा कि ORDER BY idORDER BY created_at से थोड़ा तेज है।

+0

MySQL क्लस्टर इंडेक्स के बारे में परवाह नहीं करता है। InnoDB टेबल निर्माण क्रम में रिकॉर्ड स्टोर करने की संभावना नहीं है। – Javier

+0

@ जेवियर: आपकी टिप्पणी के लिए धन्यवाद। मैंने क्लस्टर इंडेक्स के बारे में प्रलेखन के लिए एक लिंक जोड़ा है, और दस्तावेज़ीकरण से उद्धृत किया है। –

+0

हम ... मैं सही खड़ा हूँ। जब मैं नहीं देख रहा था तो उन्हें इनो डीबी कार्यान्वयन में शामिल होना चाहिए था। – Javier

3

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

3

प्रविष्टि आदेश द्वारा आईडी ऑर्डर द्वारा ऑर्डर करना।

यदि आपके पास ऐसे मामलों का उपयोग किया गया है जहां सम्मिलन में देरी हो सकती है, उदाहरण के लिए बैच प्रक्रिया, तो आपको समय के अनुसार क्रमबद्ध करने के लिए create_at द्वारा ऑर्डर करना होगा।

दोनों स्वीकार्य हैं यदि वे आपकी आवश्यकताओं को पूरा करते हैं।

5

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

आप इस मामले में इस तालिका

ID creation_date 
1 2010-10-25 
2 2010-10-26 
3 2012-03-05 

है, बजाय CREATION_DATE कार्यों की आईडी पर छँटाई कहो।

अब भविष्य में आप महसूस करते हैं, ओह, व्हाउप्स, आपको रिकॉर्ड आईडी # 2 से 2010-09-17 की निर्माण तिथि बदलनी है। आईडी का उपयोग कर अब उसी क्रम में रिकॉर्ड की रिपोर्ट आपका प्रकार:

1 2010-10-25 
2 2010-09-17 
3 2012-03-05 

भी नई तारीख के साथ ही वे किया जाना चाहिए: इस प्रयोजन के लिए डेटा उपयोग कॉलम है कि वे इस प्रकार थे:

2 2010-09-17 
1 2010-10-25 
3 2012-03-05 

लघु संस्करण बनाया था। डेटा के दुष्प्रभावों पर भरोसा न करें।