Version imprimable
Bonjour,
je suis en train d'étudier la migration d'une base paradox en mysql (voir SQL server ou Oracle suivant les contextes), et j'ai remarqué que les champs de type datetime sont reconnu par dbexpress en TSQLTimeStamp.
Y a t il une perte de performances entre les deux ? Le format TDateTime a t il été abandonné ?
Tout d'abord il faut savoir que le TDateTime est un nombre en virgule flotante, donc une valeur approchée.
La partie entière désigne la date (Nombre de jours écoulés depuis une date de référence), tandis que la partie décimal désigne l'heure (fraction de la journée écoulée).
Or dans une base de données, on peut stocker des dates beaucoup plus précises (en général, les SGBD vont au minimum jusqu'aux millisecondes, voir plus précis encore). Et surtout, ils stockent des valeurs exactes.
On ne peut pas avoir cette précision dans un TDatetime.
De plus les SGBD ne stockent pas les dates en virgules flotantes mais dans un format fixe (souvent propriétaire), plus proche du TSQLTimeStamp.
Pour ce qui est des performances, il faut également savoir que Paradox ne stocke pas les dates en TDatetime non plus. La conversion est faite à la volé, chaque fois que tu lis le champ.
En résumé, le TSQLTimeStamp est beaucoup plus précis que le TDatetime. Question performance, je ne saurais pas dire lequel est le plus rapide. Ca dépend certainement de la façon dont ton appli est codée.
Mais de toute façon, l'écart de performances n'est sûrement pas significatif, ni perceptible...
Dans delphi j'ai vu que le TSQLTimeSTampField était un packed record composé de word pour chaque éléments d'une date (date, hour, second....) qui, à l'appel de la méthode asdatetime, faisait un encodedate.
Au niveau SGBD et SQL comment cela est stocké ? Au niveau d'un index sur une date y a t il un gain ou une perte de performances ?
Je n'ai pas besoin d'une précision aussi fine que le TimeStamp (c'est plus de l'ordre de la minute) mais il semble que delphi utilise ce type de donnée dés qu'il identifie qu'un type de donnée date (date, datetime, timestamp) a été choisie pour le champ d'une base de donnée.
Je me pose la question parce que justement avant on manipulé un flottant (comparaison, décalage....) et maintenant cela deviendrait un packed record (avec toutes ces procedures pour le recomposer ou le décomposer)....
Le format de stockage des dates par les SGBD est généralement un format propriétaire et dépend d'un SGBD à l'autre.
Je ne sais pas ce qu'il en ait pour MySQL.
Mais Oracle par exemple, utilise un encodage un peu similaire (disons que la date est également décomposée en plusieurs parties : Annee, mois, jours, h, min, sec, le tout sur 7 octets.
Pour SQL Server, le DBDATETIME est presque exactement celui du TSQLTimeStampField de Delphi. Les deux ne diffèrent qu'a partir de l'encodage des ms si je me souviens bien.
L'index est géré par le SGBD. Je ne sais pas comment il fait sa sauce, mais des comparaisons sur des entiers, même regroupés dans un record doivent quand même être plus rapide qu'avec des flottants...Citation:
Au niveau d'un index sur une date y a t il un gain ou une perte de performances ?
Désolé quand je parlais index je parlais des index géré dans un Tclientdataset (indexdefs). Mais en te lisant il est clair que cela doit effectivement être performant voir optimisé....:roll:
Bon je vais voir pour l'utilisation des TSQLTimeStampField...à suivre
Merci en tout cas Franck SORIANO :king:
Passer de Paradox à MySQL, SQL Server ou Oracle : je me pose plusieurs questions :Citation:
Envoyé par HumanTool
- ton application devait être très lente avec Paradox ?
- pourquoi ne pas envisager Firebird ?
tu as des outils qui te permettent des datapump assez facilement : http://www.clevercomponents.com/down...dpdownload.asp
Heu...non pas lente du tout...????tout dépend des choix fait à la base (application 3 tier) et son utilisation. Le BDE est deprecated, donc rester sous paradox n'a pas de sens si on veut avancer....mais pour paradox les préjugés ont la vie dur.....:aie:Citation:
Envoyé par VLDG
Pourquoi pas firebird ? oui pourquoi pas vu que le but est d'être multi base...mais MySQL, Oracle, SQL serveur sont les plus courant donc mon étude porte avant tout sur ces SGBD.
Ensuite mes besoins ne sont pas juste une question de dump de données....mais merci pour le lien
pas avec Delphi : http://www.developpez.net/forums/d26...r-sgbd-delphi/Citation:
Envoyé par HumanTool
De plus Firebird est la seul base gratuite :
- MySQL est gratuite que si tu fais du GPL. Pour les petites applications, c'est ce qu'il y a de plus chère !
- SQL Serveur Express et Oracle Express sont gratuites mais ils sont propriétaires et il y a des limitations
MySQL a encore quelques manques (backup à chaud je pense que tu n'utilises pas encore la version 6)
Les composants IBS en sont pour quelque chose....Citation:
Ce sondage à pour but de recueillir des informations sur votre (vos) expérience(s) professionnelle pour ce qui est de l'utilisation d'un SGBD particulier avec Delphi.
Mais là n'est pas la question : "MySQL, Oracle, SQL serveur sont les plus courant" dans le monde
Je ne sais pas s'il y a déja eu débat, mais dire à un client qui vous pose la question "sous quel SGBD vous tournez ?", que l'on tourne sous Firebird est moins rassurant pour le client que de répondre MySQL ou Oracle ou SQL Server.
Attention ne me faite pas dire ce que je n'ai pas dit, Firebird est un bon SGBD.
N'oubliez pas que je cherche à avoir des "Fields" dans les ClientDataset suffisamment génériques pouvoir faire du multibase. Je ne cherche pas à alimenter les querelles sur qui a la plus grosse !
Paradox a toujours été stable pour nous et en utilisation 3 tiers la montée en charge a été très bonne. Cependant cela à souvent fait grimacer les responsables informatiques lorsqu'on leur disait qu'elle base de données on utilisait (voir on a eu ce genre de dénigrement à l'encontre de Paradox et de ces performances).