Bonjour,
 
Je suis en train de faire une BD et j'ai besoin de savoir la valeur max q'un int(11) peut atteindre.
 
Merci de votre aide.

Je ne suis pas certain qu'il y ait un standard pour cela.
Par exemple, je ne crois pas qu'une version 32-bit d'Oracle accepte une telle définition.
A la place, Oracle, et d'autres SGBD accepte Number(11).
Number(11) a pour valeur maximale 10 puissance 11.
 
Sur une machine 32-bit, un entier ne dépasse jamais 2 puissance 32, qui est égal à 4294967296, qui est inférieur à 10 puissance 11, et dans ce cas, il me parait probable que le SGBD tronquerait la valeur à 2 puissance 32.
Sur une machine 64-bit, un entier est plus grand que 10 puissance 11, et dans ce cas, la valeur maximale de int(11) serait 10 puissance 11.

4294967296? OK ça me laisse de la marge alors déjà. Je te remercie.
 
Mais dans ce cas, mettre int(11) ou int(4000) ne change pas grand chose...

Pour info, extrait de la documentation SQL Server :
 

Oui mais alors ça fait quoi dans ce cas de définir une taille à un entier?

 
comme précisé, il s'agit d'une info concernant sql server, pour lequel on ne spécifie pas de "largeur" de int.

c'est quoi ce sgbd qui permet int(11) ?
 
sous sql server par exemple, qui accepte un size au type int, n'acceptera jamais int(11)... ca voudrait dire que ton int est stocké que 11 octets !
 
(soit 2^87-1 !) (faut pas oublier que les types sont signé )
 
normalement, c'est int(4) (32 bits). on peut mettre int(8) pour avoir un bigint (64 bits), mais aussi int(2) (16 bits) pour smallint et int(1) (8 bits) pour tinyint. aucune autre valeur n'est acceptable...

comme je viens d'indiquer, sous SQL Server, tu peux déclarer une colonne int(1). elle va être enregistrée comme un tinyint

 
ah ? c'est étrange, je bosse sous SQL Server 2000 et si je tente une créa de colonne int(1) j'ai un joli :
 
Column or parameter #1: Cannot specify a column width on data type int.
 
ceci dit je n'en ai nul besoin

MySQL permet une déclaration de type INT(11) mais ça n'a aucune influence sur le stockage de la valeur, qui restera un entier signé.
 
Ca a simplement une influence sur l'affichage des données.
 
Une valeur de type INT sera donc toujours un entier signé, sur 32 bits, donc pouvant accepter des valeurs allant jusque 2 147 483 647.

hmmm, faudra que je vérifie avec 2005. c con, j'ai plus de 7.0. c'était peut-être sur cette version que ça marchait.

 
Est-il possible de créer des clés primaires et secondaire de type bigint en MySQL et d'avoir des valeurs max de 9 223 372 036 854 775 807?
 
Est-ce que vous pensez que si j'ai à peu près 1 000 000 000 de données en plus par ans dans ma base, j'aurai des gros pbs de lenteurs d'accès au bout de 10 ans d'utilisation?

oui, seuls les champs de type blob/clob ne peuvent être utilisés comme clé. tous les autres types sont censés etre utilisables comme clés.
 
pour ce qui est d'avoir des milliards de lignes dans la table, dans tous les cas, oui, ce sera forcément plus lent que si tu as 10 lignes.
 
ensuite, le problème de lenteur va surtout venir de la façon dont tu accèdes ensuite aux infos. il te faudra faire des index pertinants.
 
sinon, pour les clés primaires, on utilise généralement le type "numeric/decimal/number/..." qui consiste en un nombre pouvant avoir jusqu'à 25 à 40 chiffres significatifs selon le SGBD. pour l'indexation, ils sont très performants, par contre extrêment lents pour les calculs, à cause de le représentation mémoire qui n'est pas numérique.

 
Merci de ta réponse complète. En fait j'ai déjà créé ma BD qui utilise des tables InnoDB.  
Si j'ai bien compris, si je déclare mes clés en numéric, je peux donc avoir des nombres de 40 chiffres. Donc d'une taille max de  
9 999 999 999 999 999 999 999 999 999 999 999 999 999, soit 9,9999...x10¨^39
 
Je connais pas très bien le système d'index.  
Tu pourrais me dire en gros comment ça marche?
 
Est-ce que le fait de manipuler des tables InnoDB implique que l'on utilise forcément les index?  
 
Dernière question, je fais héberger ma base (qui est à usage professionnel). L'hébergeur me garantit une bande passante entre 5 et 10 Go/s. Est-ce que si je stocke 10^30 enregistrements, ça va ramer à fond? Si oui, comment faire pour optimiser MySQL et m'assurer que ça ramera pas?
Pour infos, je vais être hébergé sur un serveur dédié Bi-Proc à 3Ghz, 3Go RAM sur un disque de 73Go.
 
Merci bcp de vos réponses les gars!

alors, dans l'ordre :
-> j'ai dit "entre 25 et 40 chiffres selon le SGBD. pour my sql, je ne sais pas combien ça fait. plus qu'un bigint en tout cas.
-> imagine, tu as un livre. chaque mot à une position dans le livre (on fait abstraction des pages). je te demande à quelles position se trouve le mot "maison". tu n'as d'autre choix que de lire l'intégralité du livre pour retrouver toutes les occurences du mot. t'en a donc pour un certain temps. le sgbd, il fait la même chose quand tu lui demande une liste de lignes provenant d'une table. on voit tout de suite qu'avec des millards de lignes, ça va prendre du temps. un index sert donc à préparer le travail : imagine que tu crées un dictionnaire trié par ordre alphabétique, dans lequel tu listes tous les mots existants dans le livre. derrière chaque mot, tu vas mettre la liste de toutes les positions auxquelles on trouve le mot dans le livre. ainsi, si je te demande à nouveau où se trouve "maison". en quelques instants, tu le retrouves dans le dictonnaire et tu peux me donner la liste de chaque position. tu n'a donc plus aucune difficulté à les retrouver dans le livre. ça, c'est un index. tu vois immédiatement l'intérêt que ça peut avoir quand on a beaucoup de lignes. en revanche, pour construire l'index, ça prend plus de temps que d'écrire simplement dans la table, surtout s'il faut faire des décallages. par défaut, une clé primaire est indexée en "cluster", c'est à dire que les lignes sont réorganisées physiquement sur le disque dans le même ordre. ça provoque des trous quand on supprime des données, mais ça a l'avantage d'être extrêment rapide lors des recherches, puisque les données dans l'index sont dans le même ordre que sur le disque. mais rien ne t'empêche de créer d'autres index, composés ou non. y'a quelques topics (dont un de moi) qui traînent sur le forum qui expliquent le fonctionnement des index, et comment s'assurer qu'on a créé les index les plus pertinants.
-> la taille de la base et la bande passante de ton site n'ont absolument aucun rapport. je doute que tu t'amuses à faire beaucoup de "select * from matable" sans filtres. hors, quand tu fais une requête, seul le résultat de cette dernière sort du serveur. donc si tu fais un "select * fro matable where id = 124557886543687654376543876543, même si t'as effectivement 10^30 lignes dans ta table, seule une ligne va se balader sur le réseau. pour le reste, la machine me semble convenable. il faut surtout que tu contrôles deux choses :
- combien de requêtes par seconde en pic
- volume physique des tables
- volume des résultats
 
en effet, mettons que tu as une requête complexe qui met 3 secondes à retourner une ligne. si tu as plus de 20 requêtes par minute, tu risques l'effondrement du serveur, le nombre de requêtes simultannées ne faisant qu'augmenter.
ensuite, si tu as 1 000 000 000 lignes par ans, en comptant en moyenne 2 Ko par ligne, ça fait :
1 000 000 000 x 2 048 octets = 1,9 To par an... Tes 73 Go vont être justes
 
Ceci dit, 1 000 000 000 lignes de 2 Ko par an, ça me semble beaucoup. Mais dans tous les cas, 73 Go, ça me semble ridicule pour une base avec autant de lignes. Au pire, si c'est un serveur dédié, il ne sera jamais trop tard pour demander à l'hébergeur de rajouter du disque...
 
On trouve le même problème avec la mémoire. 3 Go de RAM, c'est correct. A condition de ne pas partir dans des délires de sous-requêtes imbriquées sur de tels volumes.

Merci de tout ceci, c'est vraiment très complet!
 
Que penses tu du fait d'utiliser des numeric pour les clés, sans gestion d'index? Je risque pas d'atteindre des temps de réponse égaux à ceux que tu as en faisant tourner winxp sur un Pentium 100 256 Mo RAM?
Je veux dire, au bout de 10 ans d'utilisation et 10^35 enregistrements dans la base, on pourra toujours accéder aux données facilement? Je conçois qu'il y aura quand même un peu de délai, mais dans la mesure ou je fais des requêtes simples avec peu d'INNER JOIN (4 maxi), les temps de réponses et d'affichage seront quand même très faibles?
 
Merci de ton aide.

D'ailleurs, quand je veux créer un numeric sous Power AMC et que je génère mon SQL, j'obtiens numeric(8,0). Le 8 signifie bien la taille en octets du nombre stocké. Est-ce que cela veut dire que la valeur max sera forcément un nombre de 8 octets? Et donc pas possible de sotcker un nombre de 25 à 40 chiffres?
Dans ce cas, quel est le bon format pour numeric pour que je puisse stocker des nombres les plus grands possibles?

Petite correction, je vais quand même utiliser des index, mais pour les données les plus recherchées seulement

dans la mesure où tu as un grand volume d'infos et que tu n'accès pas aux lignes par un index, tu auras forcément des temps de réponse à chier, même si tu n'as que 1000 lignes : il faudra que le SGBD se tape la lectue de toute la table. avec 10^35 lignes, ça représente plusieurs Go...

non, numeric(8,0) signifie un nombre avec une précision de 0 chiffres donc 0 après la virgule.

dans power amc, tu peux spécifier la taille d'un champ numéric. donc tu dis que c'est un numeric(30)...

 
Cool, merci encore!
 
- Est-il préférable de se baser sur des tables MyISAM que l'on peut optimiser, et donc réutiliser les clés supprimées?
- Quand je génère mon SQL sous Power AMC, je n'ai qu'à choisir de générer les index et ceux-ci seront créés automatiquement, cela suffit-il ensuite à MySQL?

=> ne ne peux rien te dire concernant les performances d'un type de fichier à l'autre. déjà, ça dépend à 100% de ton utilisation, et surtout, je connais pas les spécificités de chacun. regarde déjà si y'en a un qui supporte pas plus de 8 Go, ça sera un bon début : il sera inutilisable )
=> non, power amc va te créer les index de clé primaire et de foreign key (créés de toute façon automatiquement lorsque tu crée les clés dans la base)
 
on va imaginer que ta table de 10000000000000000000000 lignes contient des lignes de commande.
on va donc avoir les champs :
 
id
cde_id
numero_ligne
produit_id
quantite
prix
 
avec :
id : clé primaire (perso, je préfère une clé composée mais bon)
produit_id : clé étrangère qui pointe sur la table des produits
cde_id : clé étrangère qui pointe sur la table de commandes
numero_ligne : numéro de la ligne dans la commande
 
il y a fort à parier que tu ne va jamais chercher une ligne de commande par son identifiant "id", donc l'index par défaut est inutile
par contre, il y a fort à parier que tu vas rechercher des lignes de commande via leur numéro de commande.
ainsi, cde_id doit absolument être indexé.
même mieux, tu voudras aussi certainement retrouver une ligne de commande par son numéro de commande, mais aussi son numéro de ligne. et dans tous les cas, tes lignes de commandes seront triés par numéro de ligne. ainsi, plutôt qu'un index sur cde_id, tu va directement faire un index unique (bien plus performant) sur (cde_id, numero_ligne)
 
a nouveau, tu vas vouloir chercher des lignes de commande par produit, afin de faire des stats par exemple. donc produit_id soit aussi faire l'objet d'un index.
 
en bref, les index ne portent pas que sur la clé primaire, qui n'est pas toujours le critère de recherche le plus utilisé, et surtout, sont totalement dépendant des données qu'on met dans la table. ainsi, power amc ne peut en aucun cas te faire les bons index de façon automatisée.

Je viens de lire tout ce qui a été dit au dessus, qui est très pertinent.
 
Je tiens quand même à ajouter quelques précisions:
- Si tu utilises de tables de type MyISAM, alors tu ne pourra pas créer de Clusterd Index, car ces tables sont par définition des tables de type HEAP (cad que les enregistrements sont mis sur le système de fichier les uns après les autres au fur et à mesure de leur insertion). Ce n'est cependant pas très grave, car un index reste un index, et même s'il n'est pas clustered, il te sera néécessaire dans ton cas.
- Concernant ta problématique qui consiste à choisir entre MyISAM et InnoDB, et sous couvert que les tables MyISAM puissent être suffisamment grosses (mais je pense que c'est le cas), la question de savoir si tu dois utiliser l'un ou l'autre des deux systèmes, revient à te poser les questions suivantes:
  -Y aura t il des accès concurrents à répétition en écriture? Car il faut savoir qu'un enregistrement de donnée sur une table MyISAM en écriture va te bloquer toute la table (TABLE LOCK) alors qu'une table de type InnoDB va te proposer un niveau de granularité plus fin (du type Row Lock ou presque), mais bien entendu à un coût plus élevé.
  -As tu besoin de transactions? Si c'est le cas, alors ici aussi, il te faudra t'orienter vers du InnoDB
 
Mais sinon, si la réponse à ces deux questions est négative, je te conseillerais de t'orienter vers du MyISAM, car il s'avère que ce système est vraiument super efficace, et très rapide.
 
Enfin, à toi de voir.

Merci BCP pour ta réponse. Et je dois le préciser où dans mon code SQL que je veux créer des tables MyISAM et pas InnoDB?