J'ai croisé une fois en prestation une entreprise qui pronait l'utilisation
systematique des Numeric dans tous les cas, et jamais de int, money,
decimal, real etc etc...
mis à part l'habituelle inadéquation entre base 2 et base 10 pour le float,
je ne comprend pas... qu'est-ce que c'est sensé apporter pour int par
exemple ? prime abord, je ne vois pas d'avantage pour l'aspect définition,
ni pour celui de l'efficacité, quant à celui de la place occupée je ne sais
pas vraiment... c'est une crainte systématique de l'overflow pour des sums
ou quelque chose de ce gout ?
merci d'avance de m'aider à mettre de la lumiere la dedans.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred BROUARD
Jean BONBEUR a écrit :
Bonjour
J'ai croisé une fois en prestation une entreprise qui pronait l'utilisation systematique des Numeric dans tous les cas, et jamais de int, money, decimal, real etc etc...
money n'existe pas en SQL et sa défintion dans SQL Server est non seulement floue mais parfaitement inadéquate.
Quant aux entiers ils s'avèrent plus rapide en calculs.
Pour les real et float ils sont aussi plus rapide en calculs que les decimal...
L'intégrisme qui consiste à dir qu'il ne faut pas utiliser autre chose que le decimal est une véritable stupidité comme tout intégrisme d'ailleurs. Il convient d'utiliser le type adéquat en fonction de la problématique auquel on doit faire face.
Exemple : comptabilité => décimal(x, 2) sauf pour ce qui est quantité (float) ou encore taux (par exemple conversion Franc/euro : decimal (6,5).
A +
mis à part l'habituelle inadéquation entre base 2 et base 10 pour le float, je ne comprend pas... qu'est-ce que c'est sensé apporter pour int par exemple ? prime abord, je ne vois pas d'avantage pour l'aspect définition, ni pour celui de l'efficacité, quant à celui de la place occupée je ne sais pas vraiment... c'est une crainte systématique de l'overflow pour des sums ou quelque chose de ce gout ?
merci d'avance de m'aider à mettre de la lumiere la dedans.
Cordialement,
Frédéric DIDIER
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Jean BONBEUR a écrit :
Bonjour
J'ai croisé une fois en prestation une entreprise qui pronait l'utilisation
systematique des Numeric dans tous les cas, et jamais de int, money,
decimal, real etc etc...
money n'existe pas en SQL et sa défintion dans SQL Server est non
seulement floue mais parfaitement inadéquate.
Quant aux entiers ils s'avèrent plus rapide en calculs.
Pour les real et float ils sont aussi plus rapide en calculs que les
decimal...
L'intégrisme qui consiste à dir qu'il ne faut pas utiliser autre chose
que le decimal est une véritable stupidité comme tout intégrisme d'ailleurs.
Il convient d'utiliser le type adéquat en fonction de la problématique
auquel on doit faire face.
Exemple : comptabilité => décimal(x, 2) sauf pour ce qui est quantité
(float) ou encore taux (par exemple conversion Franc/euro : decimal (6,5).
A +
mis à part l'habituelle inadéquation entre base 2 et base 10 pour le float,
je ne comprend pas... qu'est-ce que c'est sensé apporter pour int par
exemple ? prime abord, je ne vois pas d'avantage pour l'aspect définition,
ni pour celui de l'efficacité, quant à celui de la place occupée je ne sais
pas vraiment... c'est une crainte systématique de l'overflow pour des sums
ou quelque chose de ce gout ?
merci d'avance de m'aider à mettre de la lumiere la dedans.
Cordialement,
Frédéric DIDIER
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
J'ai croisé une fois en prestation une entreprise qui pronait l'utilisation systematique des Numeric dans tous les cas, et jamais de int, money, decimal, real etc etc...
money n'existe pas en SQL et sa défintion dans SQL Server est non seulement floue mais parfaitement inadéquate.
Quant aux entiers ils s'avèrent plus rapide en calculs.
Pour les real et float ils sont aussi plus rapide en calculs que les decimal...
L'intégrisme qui consiste à dir qu'il ne faut pas utiliser autre chose que le decimal est une véritable stupidité comme tout intégrisme d'ailleurs. Il convient d'utiliser le type adéquat en fonction de la problématique auquel on doit faire face.
Exemple : comptabilité => décimal(x, 2) sauf pour ce qui est quantité (float) ou encore taux (par exemple conversion Franc/euro : decimal (6,5).
A +
mis à part l'habituelle inadéquation entre base 2 et base 10 pour le float, je ne comprend pas... qu'est-ce que c'est sensé apporter pour int par exemple ? prime abord, je ne vois pas d'avantage pour l'aspect définition, ni pour celui de l'efficacité, quant à celui de la place occupée je ne sais pas vraiment... c'est une crainte systématique de l'overflow pour des sums ou quelque chose de ce gout ?
merci d'avance de m'aider à mettre de la lumiere la dedans.
Cordialement,
Frédéric DIDIER
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
