मुझे लगता है कि विभिन्न स्ट्रिंग, दिनांक और संख्यात्मक प्रारूपों पर आगे और पीछे स्विच करने की तुलना में देशी डेटाटाइम गणित का उपयोग करना अधिक कुशल है।
DECLARE @julian VARCHAR(6) = '111186';
SELECT DATEADD(YEAR,
100*CONVERT(INT, LEFT(@julian,1))
+10*CONVERT(INT, SUBSTRING(@julian, 2,1))
+CONVERT(INT, SUBSTRING(@julian,3,1)),
DATEADD(DAY, CONVERT(INT,SUBSTRING(@julian, 4, 3))-1,
0));
परिणाम:
===================
2011-07-05 00:00:00
यह मानते हुए कि यह डेटा अक्सर नहीं बदलता है, वास्तव में तारीख को एक परिकलित कॉलम के रूप में संग्रहीत करना अधिक कुशल हो सकता है (यही कारण है कि मैंने 0
की आधार तिथि को चुना है। कुछ स्ट्रिंग प्रतिनिधित्व के बजाय, जो नियतत्ववाद के मुद्दों को स्तंभ को बने रहने और संभावित रूप से अनुक्रमित होने से रोकता है)।
CREATE TABLE dbo.JDEDates
(
JDEDate VARCHAR(6),
GregorianDate AS CONVERT(SMALLDATETIME,
DATEADD(YEAR,
100*CONVERT(INT, LEFT(RIGHT('0'+JDEDate,6),1))
+10*CONVERT(INT, SUBSTRING(RIGHT('0'+JDEDate,6), 2,1))
+CONVERT(INT, SUBSTRING(RIGHT('0'+JDEDate,6),3,1)),
DATEADD(DAY, CONVERT(INT, RIGHT(JDEDate, 3))-1,
0))
) PERSISTED
);
INSERT dbo.JDEDates(JDEDate) SELECT '111186';
SELECT JDEDate, GregorianDate FROM dbo.JDEDates;
परिणाम:
JDEDate GregorianDate
======= ===================
111186 2011-07-05 00:00:00
यहां तक कि अगर आप कॉलम को अनुक्रमित नहीं करते हैं, तब भी यह बदसूरत गणना को आपसे दूर छुपाता है, जारी रखा जा रहा है कि आप केवल लिखित समय पर भुगतान करते हैं, क्योंकि जब भी उस कॉलम को संदर्भित किया जाता है, तो यह आपको क्वेरी समय पर महंगे कार्यात्मक संचालन करने का कारण नहीं बनता है। ...