Devrais-je créer une table enfant sans clé primaire?


0

Je conçois une base de données avec une table enfant pouvant contenir des milliards d'enregistrements dans le futur.J'essaie donc d'utiliser le moins possible de champs (et de plus petits).

J'envisage donc de ne pas utiliser de clé primaire, car ce devrait être un bigint, mais je ne l'emploierai jamais dans mes requêtes (cette table enfant n'aura jamais une relation 1-N).

Une clé primaire est-elle utile pour autre chose que l'interrogation et la jointure?Je suppose que Mysql dispose d’un autre système pour distinguer un enregistrement d’un autre, ou est-ce que je me trompe?

Merci beaucoup

Edit: ma déclaration de création

CREATE TABLE 'receipt_line' (
    'id' bigint(20) unsigned NOT NULL,
    'receipt_id' mediumint(8) unsigned NOT NULL,
    'prod_id' smallint(5) unsigned NOT NULL,
    'coupon_id' smallint(5) unsigned DEFAULT NULL,
    'price' decimal(5,2) NOT NULL,
    'qty' decimal(4,2) NOT NULL
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;

ALTER TABLE 'receipt_line '
    ADD PRIMARY KEY ('id'),
    ADD KEY 'id ticket' ('receipt_id'),
    ADD KEY 'id produit' ('prod_id'),
    ADD KEY 'id coupon' ('coupon_id'),

De toute évidence, la table parente est Ticket et j'ai d'autres tables liées (produit, coupon). Le champ id n'est lié à rien.Les autres clés ne sont pas uniques.

  0

Ils facilitent l'identification des enregistrements enfants spécifiques.Dites qu'un enregistrement enfant doit être mis à jour ultérieurement, comment allez-vous l'identifier de manière unique pour l'instruction de mise à jour? 16 nov.. 152015-11-16 21:37:14

  0

Je ne mettrai pas à jour les enregistrements.Je vais seulement insérer ou supprimer en utilisant d'autres clés. 17 nov.. 152015-11-17 08:03:54

  0

Il est difficile de comprendre pourquoi vous ne pensez pas avoir besoin d'une clé unique.Veuillez expliquer pourquoi votre clé principale n’est pas simplement la combinaison de 'reçu_id',' prod_id' et 'coupon_id'.Il semble que vous voulez en venir à ceci ** étant une clé primaire composée **.Vous demandez-vous si vous devez ajouter une clé _surrogate_? 17 nov.. 152015-11-17 15:11:01

  0

La combinaison de 'reçu_id',' prod_id' et 'coupon_id' ne sera pas unique.Et je ne pense pas avoir besoin d'une clé unique, car je ne l'utiliserai dans aucune de mes requêtes.Donc je ne sais pas si le primaire est essentiel pour mysql lui-même. 18 nov.. 152015-11-18 14:19:56

  0

Montrez-nous les 'SELECTs' importants.Nous pouvons en déduire quels index sont importants.[_More info_] (http://mysql.rjweb.org/doc.php/index_cookbook_mysql). 03 déc.. 152015-12-03 04:33:55

  0

'SELECT * FROM reçu_line WHERE reçu_id =?' Ou 'SELECT COUNT (*) FROM reçu_line WHERE prod_id =?' Ou 'SELECT * FROM reçu_line WHERE coupon_id =?AND reçu_id =? 'Comme je l’ai dit, je n’utiliserai jamais le primaire.Mais comme Karoly me l'a expliqué, ce primaire sera automatiquement créé par Inodb si je ne le souhaite pas. 04 déc.. 152015-12-04 09:24:45

0

Deux choses importantes dans votre cas concernant les clés primaires dans InnoDB:

  1. Les enregistrements sont stockés dans une arborescence B + sur la clé primaire
  2. Votre clé primaire sera ajoutée à chaque index secondaire

Inconvénients de ne pas avoir une seule PK à incrémentation automatique:

  • Avec une clé naturelle plus grande, vous perdez beaucoup de place dans vos index secondaires, ce qui, je le vois, vous en aurez beaucoup.
  • Étant donné que la clé primaire ne se trouve pas dans un nombre incrémentiel continu, les fractionnements de pages se produiront plus fréquemment -> un temps d'insertion plus lent et une fragmentation accrue, ce qui augmentera encore la taille de votre espace table, même si la taille nette peut être plus petite.

Inconvénients d'avoir une PK à incrémentation automatique:

  • Les recherches sur l'index secondaire peuvent être plus lentes, mais avec l'index de hachage adaptatif, il est assez bien géré.

Avec InnoDB, la règle empirique est toujours d'utiliser la clé primaire auto_increment et de ne s'écarter de cette règle que si vous voulez explicitement savoir pourquoi vous déviez.Avec ce que vous pouvez économiser avec 4 ou 8 octets/ligne, vous perdrez plus sur la fragmentation et la plus grande taille d’index.

La seule fois où vous bénéficiez réellement d'une clé primaire plus grande, composite ou naturelle, est si c'est la seule façon d'interroger la table.Si d'autres index secondaires entrent en jeu, il est préférable d'avoir cette seule colonne PK autoinc.

  0

Merci, mais ma question ne portait pas sur l'utilisation d'un pk à incrémentation automatique OU d'une clé naturelle.Il s’agissait de ne pas utiliser de primaire du tout ... 18 nov.. 152015-11-18 14:21:36

  0

A propos de votre description de la clé primaire dans InnoDB.Comment les enregistrements sont-ils stockés dans l'arborescence B + lorsqu'il n'y a pas de clé primaire? 18 nov.. 152015-11-18 14:25:16

  0

Je pense que je n'ai pas été clair à ce sujet.Pardon!Dans InnoDB, il y a toujours une clé primaire.Même si vous n'en spécifiez pas un, InnoDB en créera un "caché" et les mêmes règles s'appliquent. 19 nov.. 152015-11-19 12:30:57

  0

Ok, c'est intéressant!Et comment InnoDB choisit-il la longueur de cette clé cachée? 19 nov.. 152015-11-19 14:15:12

  0

Si vous avez une clé unique, la première qui n'a que des colonnes non nulles sera utilisée.Sinon, Innodb créera un octet de 6 octets incrémentant en permanence (comme auto_increment).Des informations détaillées peuvent être trouvées ici: http://dev.mysql.com/doc/refman/5.5/en/innodb-index-types.html 19 nov.. 152015-11-19 14:25:00

  0

Je marque votre réponse comme étant correcte, mais la vraie réponse se trouve dans votre dernier commentaire.Merci beaucoup !Au fait, savez-vous ce qui se passe si le nombre de lignes est supérieur à 6 octets? 23 nov.. 152015-11-23 08:40:46


1

Si les enregistrements doivent être uniques, vous devez choisir une clé composite (plusieurs colonnes) pour les rendre uniques ou utiliser une clé primaire (unique par définition).Je pense qu'il n'y a rien de plus efficace.Si le problème est à court de valeurs you won't , you won't .Sachant maintenant que vous allezjamaisinterroger ou rejoindre sur cette table semble à courte vue.

EDIT After More Info: Si une combinaison unique du reçu_id, du prod_id et du coupon_id est unique, vous pouvez simplement l'utiliser pour établir l'unicité avec une clé primaire composée/composite et vider l'ID bigint.

  0

Les enregistrements n'ont pas besoin d'être uniques.En fait, ils ne le feront pas.Je n'ai pas peur de manquer de valeur bigint.J'ai peur d'utiliser un bigint, car cela prend beaucoup d'espace.Si je ne me trompe pas, la différence entre un int et un bigint dans une table d'un milliard d'enregistrements est de 11 Go. En fait, je vais interroger ou rejoindre cette table, mais jamais sur le primaire.Il y a d'autres clés que je vais utiliser pour cela. 17 nov.. 152015-11-17 08:11:48

  0

@Matthieu montre-nous ta déclaration 'CREATE TABLE', s'il te plaît.Existe-t-il d'autres colonnes ayant des contraintes UNIQUE? 17 nov.. 152015-11-17 11:52:25