La meilleure façon de gérer les dates antérieures à 1000 AD dans MySQL?

Je crée une base de données pour les enregistrements qui s'étendent avant 1000 AD, mais les champs MySQL Date et DateTime ne prennent en charge que les dates commençant à 1000.

Existe-t-il un moyen plus pratique que d'utiliser un type bigint pour compter les secondes avant / après le 1/1/1970 à l'aide d'un horodatage Unix ou de passer à un logiciel de base de données qui prend en charge de plus grandes plages de dates?

— David LeBauer
source

On répond assez bien à SO: stackoverflow.com/q/2487543/514119

— stanleykylee

@stanleykylee merci de l'avoir signalé. La question était différente, mais le problème a été soulevé dans les commentaires et a ensuite été répondu dans le sens de `` choisir une date de référence et utiliser un champ numérique '', avec la mise en garde `` ce serait fastidieux de coder, mais assez simple '' et ma question demande, entre autres, si c'est la meilleure alternative.

— David LeBauer

Ah, j'ai en quelque sorte manqué cela dans la question. Permettez-moi de faire facepalm et de supprimer ces commentaires ...

— jcolebrand

Réponses:

Une alternative consiste à stocker chaque partie de la date dans un champ numérique. Vous auriez donc trois champs:

year  SMALLINT     # Store positive values for AD and negative for BC years.
month TINYINT
day   TINYINT

De cette façon, il serait toujours lisible par l'homme. La plage de valeurs pour différents types de données numériques dans MySQL est disponible dans Présentation des types numériques . Les exigences de stockage sont disponibles dans Data Type Storage Requirements .

— dabest1
source

Je voudrais donner à ce +1, mais je suis presque sûr que la logique de la date serait horrible, non?

— Camilo Martin

Que diriez-vous d'avoir un seul champ où nous stockons les dates au format numérique pour par exemple 2015-10-12 10:12:05

— atpatil11

Aucun type de données de date RDBMS natif ne fera l'affaire pour les applications qui nécessitent des dates très anciennes (et pour certaines, même lointaines).

Si j'étais vous, j'utiliserais un type de chaîne pour le stockage natif et resterais avec un format significatif comme: + YYYY-MM-DD pour accueillir BC / AD et toute date future historique ou raisonnable prévisible.

Si cela peut vous aider, vous pouvez créer une classe de bibliothèque qui convertit votre format de stockage interne en un format plus présentable pour la couche d'interface utilisateur. Vous pouvez même inclure des fonctions de bibliothèque qui se convertissent en un type de date natif, si la langue de votre choix prend en charge les dates que vous aurez dans votre base de données.

— Joel Brown
source

Si vous utilisez SQL Server 2008+, DATETIME2 est la réponse . Plage de dates: 1er janvier 1 après JC jusqu'au 31 décembre 9999 AD.

— Nick Chammas

Bonne suggestion. Pour d'autres systèmes, je recommanderais en outre une CHECKcontrainte pour appliquer un format de chaîne de date. Hélas, MySQL n'applique pas de CHECK contraintes.

— Nick Chammas

@ Nick, d'accord sur DATETIME2 dans SQL Server 2008+, (je vais manquer 1753) mais OP commence avec MySQL comme son enjeu dans le sol. De plus, même DATETIME2 tombe dès que vous devez ajouter le 31 décembre 1 BC à votre calendrier :)

— Joel Brown

Vous pouvez toujours ajouter une colonne BITou BOOLEANpour indiquer la polarité de la date. :) Bien sûr, si vous faites cela, vous êtes seul si vous effectuez des calculs sur ces dates "BC". Qui sait quel genre d'ajustements de calendrier qui sont normalement pris en charge pour nous par les fonctions de bibliothèque serait manqué lors de la manipulation des "fausses" dates BC ...

— Nick Chammas

Mark, la raison pour laquelle je recommanderais une chaîne est que, tant que vous la formulez correctement, elle sera lisible par l'homme (et même dans une certaine mesure modifiable) sans aucun traitement et vous pourrez construire des fonctions spéciales de manipulation de date avec une relative facilité. Stocker des dates sous forme de nombres est terriblement, terriblement gênant, sauf si vous avez une bibliothèque de fonctions qui peuvent interpréter ce type d'encodage pour de simples humains. Bien sûr, lorsqu'une telle bibliothèque est en place, le codage d'une date sous forme de nombre est beaucoup plus judicieux.

— Joel Brown

Que diriez-vous d'avoir un seul champ flottant dans la table où nous stockons les dates au format numérique pour par exemple 2015-10-12 10:12:05 sera stocké 20151012. 101205. Il est toujours préférable d'avoir un tri sur un seul champ au lieu d'en avoir 3 ou plus différents domaines.

La logique ci-dessus ne fonctionne pas pour quelques scénarios. Ainsi, nous avons converti la date en secondes en considérant 1 jour = 86400 secondes. Utilisé négatif pour les dates BC. Cela fonctionne comme prévu.

— atpatil11
source

des nombres négatifs pour la Colombie-Britannique?

— Rob Sedgwick

151012 et 150819 seraient tous deux en 15AD, -151109 serait en 15BC

— Rob Sedgwick