Man page - hash(3)

Packages contains this manual

Available languages:

en fr es ja ru ro

Manual

hash

NOM
BIBLIOTHÈQUE
SYNOPSIS
DESCRIPTION
ERREURS
BOGUES
VOIR AUSSI
TRADUCTION

NOM

hash - MĂ©thodes d’accĂšs aux bases de donnĂ©es avec tables de hachage

BIBLIOTHÈQUE

BibliothĂšque C standard ( libc , -lc )

SYNOPSIS

#include <sys/types.h> #include <db.h>

DESCRIPTION

NOTE : cette page dĂ©crit des interfaces fournies jusqu’à la glibc 2.1. Depuis la glibc 2.2, la glibc ne fournit plus ces interfaces. Veuillez consulter les API fournies par la bibliothĂšque libdb .

La routine dbopen (3) est l’interface de bibliothĂšque des fichiers de base de donnĂ©es. L’un des formats de fichier pris en charge est la table de hachage. La description gĂ©nĂ©rale des mĂ©thodes d’accĂšs Ă  une base de donnĂ©es est fournie dans la page de manuel dbopen (3). La page prĂ©sente ne dĂ©crit que les informations spĂ©cifiques aux tables de hachage.

Les structures de hachage représentent un schéma de base de données dynamique et extensible.

La structure de donnĂ©es spĂ©cifique aux tables de hachage que l’on transmet Ă  dbopen (3) est dĂ©finie dans <db.h> ainsi :

typedef struct {
unsigned int bsize;
unsigned int ffactor;
unsigned int nelem;
unsigned int cachesize;
uint32_t (*hash)(const void *, size_t);
int lorder;
} HASHINFO;

Les éléments de cette structure sont les suivants :

bsize

dĂ©fini la taille des cases de la table (bucket size), et vaut, par dĂ©faut, 256 octets. Il est prĂ©fĂ©rable d’augmenter la taille de page pour les tables situĂ©es sur disque ayant des Ă©lĂ©ments avec beaucoup de donnĂ©es.

ffactor

indique une densitĂ© dĂ©sirĂ©e au sein de la table. Il s’agit d’une approximation du nombre de clĂ©s pouvant s’accumuler dans une seule case, ce qui dĂ©termine le moment oĂč la table doit s’agrandir ou se rĂ©trĂ©cir. La valeur par dĂ©faut est 8.

nelem

est une estimation de la taille finale de la table de hachage. S’il n’est pas configurĂ©, ou s’il est configurĂ© trop bas, la table s’agrandira quand mĂȘme correctement au fur et Ă  mesure de l’entrĂ©e des clĂ©s, bien qu’une lĂ©gĂšre dĂ©gradation des performances puisse ĂȘtre observĂ©e. La valeur par dĂ©faut est 1.

cachesize

est la taille maximale suggĂ©rĂ©e de mĂ©moire cache, en octets. Cela n’a qu’une valeur indicative , et les mĂ©thodes d’accĂšs alloueront plus de mĂ©moire plutĂŽt que d’échouer.

hash

est une fonction dĂ©finie par l’utilisateur. Comme aucune fonction de hachage ne se comporte parfaitement bien sur tout type de donnĂ©es, il peut arriver que la fonction interne soit particuliĂšrement mauvaise sur un jeu particulier de donnĂ©es. La fonction de hachage fournie par l’utilisateur doit prendre deux arguments (un pointeur sur une chaĂźne d’octets et une longueur) et renvoyer une valeur sur 32 bits utilisable comme valeur de hachage.

lorder

est l’ordre des octets pour les entiers stockĂ©s dans la base de donnĂ©es. Ce nombre doit reprĂ©senter l’ordre sous forme d’entier. Par exemple l’ordre poids faible-poids fort (big endian) est reprĂ©sentĂ© par le nombre 4321. Si lorder vaut 0 (pas d’ordre indiquĂ©), on utilise l’ordre des octets du systĂšme hĂŽte. Si le fichier existe dĂ©jĂ , la valeur spĂ©cifiĂ©e est ignorĂ©e et la valeur spĂ©cifiĂ©e lors de la crĂ©ation de l’arbre est utilisĂ©e.

Si le fichier existe dĂ©jĂ  (et si le drapeau O_TRUNC n’est pas spĂ©cifiĂ©), les valeurs spĂ©cifiĂ©es dans bsize , ffactor , lorder et nelem sont ignorĂ©es et les valeurs spĂ©cifiĂ©es lors de la crĂ©ation de l’arbre sont utilisĂ©es Ă  la place.

Si une fonction de hachage est indiquĂ©e, hash_open essaie de dĂ©terminer s’il s’agit de la mĂȘme fonction que celle indiquĂ©e lors de la crĂ©ation de la base de donnĂ©es, et Ă©choue si ce n’est pas le cas.

Des interfaces pour les routines décrites dans dbm (3), et ndbm (3) sont fournies pour la compatibilité ascendante, toutefois ces interfaces ne sont pas compatibles avec les anciens formats de fichier.

ERREURS

Les routines d’accĂšs aux tables de hachage peuvent Ă©chouer et remplir errno avec n’importe quelle erreur indiquĂ©e par la routine dbopen (3).

BOGUES

Seuls les ordres d’octets gros boutiste (big-endian) et petit boutiste (little-endian) fonctionnent.

VOIR AUSSI

btree (3), dbopen (3), mpool (3), recno (3)

Dynamic Hash Tables , Per-Ake Larson, Communications of the ACM, April 1988.

A New Hash Package for UNIX , Margo Seltzer, USENIX Proceedings, Winter 1991.

TRADUCTION

La traduction française de cette page de manuel a été créée par Christophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry Vignaud <tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@debian.org> et David Prévot <david@tilapin.org>

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n’y a aucune RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org .