Type char

Résolu
denver78610 Messages postés 29 Date d'inscription mardi 20 avril 2010 Statut Membre Dernière intervention 13 juillet 2010 - 3 mai 2010 à 12:11
denver78610 Messages postés 29 Date d'inscription mardi 20 avril 2010 Statut Membre Dernière intervention 13 juillet 2010 - 5 mai 2010 à 14:44
bonjour a tous

voila en ce moment je travail sur une très grosse base de donnée. Cette base a pour but de géré un stock. Dans un sousi d'optimisation, j'ai voulut mettre les numéros de mes tables ( clef primaire, sous la forme num[matable]) en type char, autorisant 255 valeurs. Ce qui était suffisant. Mais le type char me pose maintenent beaucoup de probleme et je ne suis malheuresment qu'un débutant. En effet dans un premier temps j'ai bloquer sur l'utilisation de l'agrégat SQL MAX qui ne fonctionne pas en char comme en int. Maintenent lorsque je récupère un numéro d'une de mes tables, j'ai quelquechose sous la forme "250 " et je ne comprend pas.Comment puis-je faire pour supprimer tout ces espaces, j'ai testé Replace mais sa ne marche pas, et plus largement Comment doi-je manipuler ce type char pour ne pas avoir de probleme? y a t-il d'autre piège que vous connaisseriez qui m'attendent?

je programme sous VB 6 et ma base est sous ACCESS 2000

voili voilou

je vous remerci d'avance!

cordialement, Denver le dernier dinosaur!!!!

16 réponses

Calade Messages postés 1207 Date d'inscription dimanche 20 avril 2003 Statut Membre Dernière intervention 4 juin 2016 10
3 mai 2010 à 14:42
Bonjour,

A l'heure où un HDD de 1TO coûte dans les 50€, faire des économies sur le nombre d'octets est un peu surréaliste. Mais bon, comme le dit Jack il serait nettement préférable de le coder en INT.

Si tu tiens malgré tout à le laisser en CHAR, sache que par défaut sous Access, une chaîne de caractères fait 50 octets de long, précise donc la longueur désiré (1 ici je pense).

Mais sache que tu risques d'avoir des problèmes.


Calade
3
denver78610 Messages postés 29 Date d'inscription mardi 20 avril 2010 Statut Membre Dernière intervention 13 juillet 2010
3 mai 2010 à 12:27
petite précision, parce que votre éditeur de texte supprime les espaces supplémentaire lui! ^^
quant je disais "sous la forme '250 '" sa voulait dir que apres le 250 j'avais plein d'espace, ce qui a pour effet de ruiné mes requetes géré sous VB. En effet lorsque j'affiche dans une msgbox ma variable requete ( dans laquel j'ai intégré l'un de mes numéro en type char) je me rend conte que tout les espaces pousse la fin de ma requete sur une autre ligne et elle n'est donc pas exécuter completement, au final elle plante soit parce qu'il manque un ou plusieur argument soit parce qu'il manque une ')' ou un ';' sa dépend de ou je met la variable num.
0
cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 79
3 mai 2010 à 13:11
Salut
Pas compris grand chose à "j'ai voulut mettre les numéros de mes tables"

"agrégat SQL MAX qui ne fonctionne pas en char comme en int"
Oui, normal
Un texte est un texte, où 200 sera toujours inférieur à 8 (le 2 est avant le 8 dans la table ascii)

La meilleure solution serait de remplacer ton Char par un Int, oui.
Un Char comporte autant de caractères que défini dans le champ.
Il aurait fallu utiliser VarChar pour qu'il ajuste à la longueur réelle du contenu du champ.

Bizarre que tu parles de Char alors que tu sembles travailler avec une base Access.
Crées-tu les tables sous VB ?

Sans exemple de tes syntaxes, difficile de t'en dire plus.

Vala
Jack, MVP VB
NB : Je ne répondrai pas aux messages privés

Le savoir est la seule matière qui s'accroit quand on la partage (Socrate)
0
denver78610 Messages postés 29 Date d'inscription mardi 20 avril 2010 Statut Membre Dernière intervention 13 juillet 2010
3 mai 2010 à 14:02
désolé si je n'ai pas été sufisement claire.

je souhaite utilisé des char a la place des int pour utilisé moin de place. Un numéro entre 0 et 255 en char ne me prendera qu'un octet alors qu'en int il me prendera 4 octets.

J'ai une table Stock dans laquel j'ai 2 numéros. Si j'utilise le type char au lieu d'int je gagne 6 octet par ligne sachant que ma table fera dans les 17 000 lignes par moi. Voila mon objectif.


quant a mon probleme, lorsque j'extrait de ma base de donnée l'un de mes numéros il est suivit par de nombreux espaces.Ces espaces pose probleme car quant j'essaye d'exécuté une requete en VB dans laquel j'ai mis un numéro en char extrait de la base de donnée, les nombreux espaces font planté ma requete, elle n'est pas prise en conte completement ( affichage des variables en mode debogage) tout ce qui suit les espaces est oublier et donc soit il me manque des valeurs, soit c'est un ';' et une ')' qu'il manque. peutetre que parmi ces espaces il y a un saut de ligne ou je ne sait quoi.


mes questions sont, pourquoi ? et comment faire pour supprimer ces espaces ?

mes tables sont créé directement en SQL sous ACCESS

Create table StockHyperFamily (numhyperfamily char, stockvaleur integer , stockvolume integer,annee smallint, mois char, numeconomicunit char, nouveau bit, CONSTRAINT cle_etrangere_StockHyperFamily_numhyperfamily FOREIGN KEY (numhyperfamily) REFERENCES HyperFamilyStock (numhyperfamily), constraint clef_etrangere_StockHyperFamily_numeconomicunit foreign key(numeconomicunit) references EconomicUnit(numeconomicunit), constraint cle_primaire_StockHyperFamily primary key(numhyperfamily, annee, mois, numeconomicunit));


voila le script de création de la table que je voudrai optimiser. J'ai bien évidement dans un premier temps utilisé des entiers mais comme expliquer un peu plus haut je souhaiterai utilisé des chars pour numhyperfamily et numeconomicunit.

suite a quelque recherche je n'ai pas trouver de type entier qui serait codé sur 1 octets. mais peutetre existe t'il?

ps : "insert into EconomicUnit(numeconomicunit, nomeconomicunit,numzone,monnaie) values (251,'CA100 LC01',250--------------------------------------------------------------------------------------------------------------------------------------------------------"
ici j'ai apepres remplacer les espaces par des tirets pour vous donner une idée de ma requete, mon numéro étant le 250 or apres la derniere guillement je devrai avoir une autre valeure elle tiré d'une liste et ");" pour finir ma requete. numzone vien d'être extrait de la table.

"insert into EconomicUnit(numeconomicunit, nomeconomicunit,numzone,monnaie) values (" & bd.counter("EconomicUnit", "numeconomicunit") & ",'" & nomeu & "'," & numzone & "," & List2.Text & ");"

voila la ligne d'insert exécuter dans mon code le numéro posant probleme étant le numzone.

voila le script de la table Economic Unit :
Create table EconomicUnit( numeconomicunit char Primary key, nomeconomicunit VARCHAR(30), numzone char, monnaie varchar(30), constraint clef_etrangere_EconomicUnit_numzone foreign key(numzone) references ZoneGeographique(numzone), constraint clef_etrangere_EconomiqueUnit_monnaie foreign key(monnaie) references ExchangeRate(monnaie));

la méthode counter du module bd permet elle de simuler un type counter SQL avec un char. elle va chercher la plus grande valeur d'un champ dans une table et la retourn incrémenté de 1. Le champ et la table étant les 2 valeurs passée en paramètre.
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
denver78610 Messages postés 29 Date d'inscription mardi 20 avril 2010 Statut Membre Dernière intervention 13 juillet 2010
3 mai 2010 à 14:41
Bon j'ai en faite réussi a réglé mon probleme. J'avai testé de supprimer les espaces avec la fonction replace mais j'avais oublier de récupéré le résultat ... En faite elle marche tres bien.il manquai aussi pas mal de cote dans ma requete, mais sa marche corectement maintenent. J'aurai quant meme aimer savoir pourquoi tout ses espaces? exist il une fonction équivalent a sizeof en vb?
0
denver78610 Messages postés 29 Date d'inscription mardi 20 avril 2010 Statut Membre Dernière intervention 13 juillet 2010
3 mai 2010 à 15:09
Il est vrai que dans ce cas prési, sur 5 ans je ne gagne que 6 a 7 mega. Bien que l'optimisation devai etre faite pour avoir une base de donnée plus facilement transportable, avec les taux de transphère d'aujourd'huit sa ne change pas grand chose, je pense passé les numéros au moin en small int ( 2 octets par valeur) et j'aurai probablement moin de probleme en small int qu'en char.

je vous remerci, passez une bonne fin de journé et a bientot

Denver, Le dernier Dinosaur!!!
0
cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 79
4 mai 2010 à 01:00
Ce qui fait vraiment l'efficacité d'une DB, ce sont les tables d'indexation.
Donc mieux vaut une bonne structure (*) avec les bonnes clés primaires, que de vouloir jouer sur la taille des champs.
(*) une bonne structure, c'est une DB dans laquelle la même info n'est pas écrite 2 fois = mieux vaut une table supplémentaire et des clés primaires en lien, que de trainer plusieurs fois un même champ dans plusieurs tables.
Exemple d'une table nominative :
Dans un des champs, tu peux mettre M., Mme, Melle, Me, Dr, etc ...
Mieux vaut créer une table qui stockera toutes ces formes de civilité associé à un Id + stocker l'Id de la civilité retenue dans la fiche nominative, que de stocker les textes "M.", "Mme" dans chaque fiche nominative.
Tu vois ce que je veux dire ?
0
denver78610 Messages postés 29 Date d'inscription mardi 20 avril 2010 Statut Membre Dernière intervention 13 juillet 2010
5 mai 2010 à 09:29
aaaaaaa mais di moi c'est très intéressant tout sa.
En gros dans ma table Stock je pourrai supprimer les attributs mois et année et créé une table moi et une table année et faire pointé mon stock sur les 2 tables. Je gagnerai en efficacité c'est sa?
0
Calade Messages postés 1207 Date d'inscription dimanche 20 avril 2003 Statut Membre Dernière intervention 4 juin 2016 10
5 mai 2010 à 09:45
Bonjour,

Pour les mois, pas besoin de table à mon avis, en principe il y a 12 par an toujours dans le même ordre, donc une simple combobox prédéfinie est suffisante à mon avis.

Pour les années, une table ici serait pour la saisie des années uniquement (la sauvegarde c'est autre chose). Pose-toi la question de quelles sont les années acceptées en saisie ( à priori je dirais l'année en cours et peut-être la précédente pour gérer le passage. Donc là encore pas de table. Enfin je dis à la lecture de tes posts, je n'ai évidemment pas lu l'analyse de ton appli.

Par contre j'ai regardé un peu ta déclaration dans ton 1er post. Tu dis travaillé avec Access, or tu ne mets jamais la taille de tes champs CHAR. Là tu te retrouves avec un champ Mois sur 50 car (le défaut sous Access), tu es donc très loin de l'optimisation voulue.


Calade
0
denver78610 Messages postés 29 Date d'inscription mardi 20 avril 2010 Statut Membre Dernière intervention 13 juillet 2010
5 mai 2010 à 09:59
5O char! durrrrr

je vais changer sa de suite!
par contre je ne comprend pas ton histoire de combobox.
Dans ma base de donnée j'ai besoin d'un context temporel enterme d'année et de mois. Un stock sans date ne corespond a rien. J'ai donc le besoin d'associer à chaque ligne de ma table stock un mois et une année.

pour vous donnée une idée j'aurai apepres 17 000 lignes de stock dans ma table par mois. Et si j'ai bien compri dans une bonne base de donnée on ne retrouve pas des valeures récurente enregistré à chaque ligne. Or les 17 000 lignes que j'ai chaque mois auront 2 champ identique, le mois et l'année. Est - t - il donc préférable de créé une table année que je pourrai allimenté facilement à la main jusqu'en 2012 ( la fin du monde ) et une table mois qui contiendrai 12 lignes comme vous pouviez vous en douté, et de faire pointé mé ligne de stock vers ses tables?
0
Calade Messages postés 1207 Date d'inscription dimanche 20 avril 2003 Statut Membre Dernière intervention 4 juin 2016 10
5 mai 2010 à 10:15
Excuse, pour les combobox, c'était à la saisie pour un nouvel enregistrement. Pour la consultation, c'est différend.

Mais je ne suis pas sur que le jeu en vaille la chandelle. Dans un cas, dans ta table stocke tu auras 2 champs (1 smallint + 1Char(2)); dans l'autre cas tu remplaceras ces 2 champs par 1 seul (Integer ou long si plus de 32000 lignes) et une autre table contenant 12 lignes par an. Sans compter les requêtes sous-jacentes.

A toi de voir et de faire tes comptes.


Calade
0
denver78610 Messages postés 29 Date d'inscription mardi 20 avril 2010 Statut Membre Dernière intervention 13 juillet 2010
5 mai 2010 à 11:06
hummm pour le coup tu n'as pas tord, je pense que les comptes sont facile a faire. Je vais la jouer facile, et laissé mes attributs

Denver, Le dernier Dinosaur!!!!
0
Calade Messages postés 1207 Date d'inscription dimanche 20 avril 2003 Statut Membre Dernière intervention 4 juin 2016 10
5 mai 2010 à 11:18
Par contre, là où cela vaut le coup et c'est surement ce que voulait dire Jack, c'est pour le nom des pièces.

En gros, une table pièces avec un ID, un nom, etc... et dans la table maître un champ où tu mettras simplement l'ID de la pièce. Ce principe n'a que des avantages, imagine si tu fais une faute dans le nom et que tu t'en aperçois plusieurs mois après si tu devais corriger toutes les occurrences dans la tables maître !


Calade
0
denver78610 Messages postés 29 Date d'inscription mardi 20 avril 2010 Statut Membre Dernière intervention 13 juillet 2010
5 mai 2010 à 14:07
aaaa mé mon ami si tu regarde le script de création de la table ( et que j'ai bien compri ce que tu voulais dir ^^) tu veras que sur l'atribut numhyperfamily (qui est en gros le nom de ma piece) il y a déja une référence vers une autre table

en effet je ne me sentait pas d'enregistré 17 000 chaine de 70 char par mois dans ma table stock ^^
0
Calade Messages postés 1207 Date d'inscription dimanche 20 avril 2003 Statut Membre Dernière intervention 4 juin 2016 10
5 mai 2010 à 14:20
Alors pas de problème.
Et bonne chance.


Calade
0
denver78610 Messages postés 29 Date d'inscription mardi 20 avril 2010 Statut Membre Dernière intervention 13 juillet 2010
5 mai 2010 à 14:44
merci pour tout et bonne continuation!
0
Rejoignez-nous