sql >> Databasteknik >  >> RDS >> Sqlserver

Konverterar JDE julianskt datum till gregorianskt

Jag tror att det är mer effektivt att använda inbyggd datetime-matematik än att växla fram och tillbaka till olika sträng-, datum- och numeriska format.

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));

Resultat:

===================
2011-07-05 00:00:00

Förutsatt att dessa data inte ändras ofta kan det vara mycket effektivare att faktiskt lagra datumet som en beräknad kolumn (det är därför jag valde basdatumet 0 istället för någon strängrepresentation, vilket skulle orsaka determinismproblem som hindrar kolumnen från att bestå och eventuellt indexeras).

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;

Resultat:

JDEDate GregorianDate
======= ===================
111186  2011-07-05 00:00:00

Även om du inte indexerar kolumnen, döljer den fortfarande den fula beräkningen från dig, om du fortsätter att betala det vid skrivtid, eftersom det inte får dig att utföra dyra funktionella operationer vid frågetid närhelst den kolumnen refereras ...



  1. MySQL-funktion för att bestämma postnummernärhet/räckvidd

  2. TypeORM OneToMany-filter i relationer påverkar inte resultatet

  3. Tips för att lagra dina MariaDB-säkerhetskopier i molnet

  4. Entity Framework Core - effektivt sätt att uppdatera Entitet som har barn baserat på JSON-representation av entitet som skickas in via webb-API