hash(3) Library Functions Manual hash(3)
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 ha-
chage.
Les structures de hachage représentent un schéma de base de données dy-
namique 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 ha-
chage. 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 sys-
tè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éci-
fié), 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 Chris-
tophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <ste-
phan.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.cou-
lon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux
<thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centra-
liens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <si-
mon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@de-
bian.org> et David Prévot <david@tilapin.org>
Cette traduction est une documentation libre ; veuillez vous reporter à
la GNU General Public License version 3
⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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⟩.
4.4 Berkeley Distribution 4 décembre 2022 hash(3)
Generated by dwww version 1.15 on Sat Jun 29 01:44:17 CEST 2024.