Datatyp för datum i databasen!

[Erik Brännlund]

Hej!
 
Jag har hackat ihop ett eget släktforskningsprogram. Data lagras (i alla fall för tillfället) i en Paradoxdatabas. Nu har jag hittils bara använt databasens datumtyp för att lagra olika händelser (född, död...). Detta orsakar problem för de händelser där inte hela datumet är känt. Någon som har ngn id? om hur det borde hanteras. Hur lagrar Disgen sådant. I botten vill jag nog fortfarande ha databasens datum. För att enkelt kunna skriva SQL-frågor där databasen själv kan hantera sorteringsordning mm.  
 
Koden hackas i Delphi förövrigt.
 
/Erik

[Åke Forsmark]

Uppriktigt sagt så har jag inte full koll på detta, men jag har experimenterat med liknande saker och kom då fram till att det bästa var att lagra datumet som en textsträng. Då kan man antingen skriva programmet så att det tolkar 1582 och 1582-02-04 på ett korrekt sätt eller så kräva inmatning typ 1582-??-?? eller hur man nu vill ha det.
 
Att tämja en databas till att hantera luddiga datum tror jag är svårt och skulle man mot förmodan lyckas så tror jag att det kan bli problem att flytta databasen mellan olika databasvarianter. Håller man sej till få typer tex heltal och text så kommer databasen att vara enkel att flytta till andra varianter som mssql eller postgresql.

[Anders Andersson]

Om man bara skall mata in och skriva ut datum, så fungerar det förstås att använda strängar för ändamålet. Om man däremot vill kunna söka efter poster med vissa datum, sortera poster kronologiskt och liknande, så är det nog effektivare om det inmatade datumet delas upp i sina beståndsdelar från början, och skall man klara osäkra och/eller okända uppgifter behövs en entydig representation av dessa.
 
Den datumrepresentation som finns i många systembibliotek är knappast användbar. Dels saknas möjlighet att ange okänt värde, dels brukar de ha problem med historiska årtal (före 1900, före gregorianska kalendern, före vår tideräknings början). Om det inte finns något standardbibliotek för detta (jag kan tänka mig att programutvecklare som arbetar inom de historiska vetenskaperna har funderat över problemet), så lär man få skriva rutinerna själv.
 
Alla rutiner för sökning och jämförelser bör klara poster där inte alla fält är ifyllda, antingen genom att ignorera dem eller genom att göra partiella jämförelser. Om jag söker efter personer födda 1809 så vill jag förstås hitta alla med detta födelseår vare sig deras exakta födelsedatum är känt eller ej. Samma sak gäller ju om jag söker efter ett sockennamn och hittar personer med en mer precis ortsangivelse. Om man ändå tänker skriva sådana sökrutiner, så kan man lika gärna göra dem användbara för såväl datum som orter och andra fält. Rena strängjämförelser är inte alltid idealiska.
 
Representationen av okända eller osäkra värden kan göras mer eller mindre avancerad. Tills för bara något decennium sedan förekom det att årtal lagrades med bara två siffror, och att årtalet 99 fick betyda när som helst i framtiden snarare än 1999! Enklast är förmodligen att ha särskilda meta-fält som anger huruvida exempelvis månaden är känd, snarare än att koda okänd månad med -1 eller 0. Det tar något mer plats, men man glömmer inte lika lätt att testa meta-fältet om det behövs för att rutinerna alls skall fungera.

[Per-Olof Persson]

Jag har haft ett liknande problem, som jag löste genom att använda två fält. Ett för datumet och ett för att ange datumets säkerhet eller noggrannhet. Då ganska lätt göra om datumet till ett intervall när du skall skriva sökrutiner.  
Du skriver in ett exakt datum i datumfältet (som du vet eller gissar) och anger i noggrannhetsfältet hur noggrannt du vet (eller tror) att datumet är.
 
Exempel med datumet 1849-01-24 och några påhittade koder:
 
1849-01-24/A. exakt datum.....1849-01-24 -- 1849-01-24
1849-01-24/B. exakt månad.....1849-01-01 -- 1849-01-31
1849-01-24/C. exakt år........1849-01-01 -- 1849-12-31
1849-01-24/D. tidigast år.....1849-01-01 -- 2999-12-31
1849-01-24/E. senast år.......1000-01-01 -- 1849-12-31
1849-01-24/F. ungefär år......1844-01-01 -- 1854-12-31
 
osv. med de koder du behöver. Fördelen med detta är dels att dina uppgifter är portabla till andra databaser, dels att sökrutinerna blir enkla. Nackdelen är att du måste hålla reda på vad noggrannhetskoderna betyder i en separat lista/tabell.
 
Jag arbetar med Access 2002 och den klarar datum från 1 jan 100 till 31 dec 9999 vilket räcker till för mina behov :-). Den håller också reda på skottdagar, men stupar naturligtvis på gamla och nya stilen (vilket man kan definiera i kodfältet, kom jag på nu). Lycka till med programskrivningen.

[Anders Andersson]

Ett ungefärligt datum kan representeras med ett intervall enligt ovanstående, men ibland kommer sig osäkerheten av en eller flera svårlästa siffror som inte nödvändigtvis är de minst signifikanta. I DISGEN kan jag ersätta valfri siffra i datumet med ett frågetecken, om jag exempelvis inte kunnat utläsa ur källan vilken månad barnet är fött. På så vis begränsar jag antalet möjliga alternativ till tolv i stället för 366. Denna metod kan givetvis också användas när man som så ofta endast känner till årtalet, men varken månad eller dagens nummer.
 
Generaliserade intervall (mellan datum A och datum B) är mer lämpade för naturvetenskapliga tidsangivelser, där osäkerheten kommer sig av inexakta mätmetoder, snarare än för forskning i historiska källskrifter där osäkerheten sitter i vad någon en gång valt att anteckna.

[Erik Brännlund]

Långt om länge har jag faktiskt gjort ett nytt datumformat. Så här gjorde jag. Konverterade datumet till julian nånting och subtraherade julian värdet för 1000-01-01. Skapade en 8-bitars mask där en 1:a representerar ett frågetecken i inmatningen. Skiftade efter mitt julian datum 10 steg (för att ge utrymme för ytterligare info). Or-ade in masken och sparade som Int32 i databasen. Detta gör att datum äldre än 2:a januari år 1000 inte fungerar men jag räknar inte med att kunna komma så långt bakåt. Inte heller kan jag hantera intervall eftersom jag då skulle ha behövt mer än 32 bitar.
/Erik