Bonsoir Nike,
Envoyé par
nike7414
En supprimant aussi les index inutiles de chaque, sans comprendre vraiment pourquoi ces index sont inutiles ?
Prenons par exemple les cas de votre définition de la table CLIENT. Vous avez doté celle-ci d’un index « primaire », car les clanculs feignants exigent que nous définissions un tel index (concept physique) pour toute clé primaire (concept relationnel) :
CREATE TABLE IF NOT EXISTS client
(
client_id INT NOT NULL AUTO_INCREMENT,
...
PRIMARY KEY (client_id),
UNIQUE INDEX client_id_UNIQUE (client_id ASC)
) ;
Mais on a là deux index strictement identiques : en supprimer un ne pénalise en rien les SELECT (et MySQL ne se servira jamais en l’occurrence du 2e index, le primaire suffisant largement à son bonheur), en revanche on va améliorer la performance des mises à jour car, par exemple l’ajout ou la suppression d’un client ne va secouer qu’un seul index au lieu de deux, et croyez-moi, mettre à jour un index ça coûte cher, à vos moments perdus vous pourrez-faire le test de ce que représente la mise en œuvre du 2e index.
Prenons l’exemple de votre description précédente de la table PRICE :
CREATE TABLE IF NOT EXISTS price (
price_id INT NOT NULL AUTO_INCREMENT,
category_id INT NOT NULL,
price_km DECIMAL(4,2) NOT NULL,
price_minimum TINYINT(4) NOT NULL,
price_disposal TINYINT(4) NOT NULL,
PRIMARY KEY (category_id, price_id),
UNIQUE INDEX price_id_UNIQUE (price_id ASC),
INDEX fk_price_category1_idx (category_id ASC),
CONSTRAINT fk_price_category1
FOREIGN KEY (category_id)
REFERENCES category (category_id)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
Cette table est dotée de 3 index. Il y a l’index « primaire », de clé {category_id, price_id} : d’accord. Il y a l’index price_id_UNIQUE de clé {price_id} : d’accord. Il y a l’index fk_price_category1_idx, de clé {category_id} et plaqué sur la clé étrangère fk_price_category1 : quelles sont les conséquences de la suppression de cet index ? Comme ci-dessus, on améliore la performance des mises à jour, quant aux SELECT portant sur la clé étrangère, il n’y a pas de bobo, car MySQL se rabattra sur l’index primaire dont le 1er attribut de la clé est aussi category_id : pas de perte de performance donc.
Envoyé par
nike7414
Pour la description du chauffeur ca se fait dans la table DRIVER où j'ai mis "LONGTEXT".
Je reprends ce que j’ai écrit dans mon message précédent, en adaptant à la table DRIVER :
Si les chauffeurs racontent leur vie, la table DRIVER risque l’obésité (et les performances d’en souffrir énormément, vu le rôle plutôt central que joue cette table), auquel cas il serait préférable de mettre en oeuvre une table ad-hoc (appelons-la par exemple DRIVER_DESCRIPTION), attachée à DRIVER, et hébergeant l’attribut description, qui disparaît alors de la table DRIVER :
[DRIVER]-||—0|-[DRIVER_DESCRIPTION]
script SQL :
CREATE TABLE driver_description (
driver_id INT NOT NULL,
description INT NOT NULL,
PRIMARY KEY (driver_id),
CONSTRAINT DRIVER_DESCRIPTION_DRIVER_FK
FOREIGN KEY (driver_id)
REFERENCES DRIVER (driver_id)
ON DELETE CASCADE
ON UPDATE NO ACTION
) ;
A cette occasion, à propos de la table DRIVER, il faudrait raboter, ajuster au mieux la taille des attributs consommant des ressources. Par exemple, est-il nécessaire que l’attribut pass occupe 255 octets ? En codant VARCHAR(255), c’est un encombrement de 256 octets, même si Raoul n’utilise que 10 caractères pour son mot de passe... Un numéro de téléphone de 30 caractères, c’est quand même beaucoup, etc.
Ce travail d’ajustement de la taille des attributs vaut bien sûr pour la table CLIENT, et même pour toutes les tables...
A faire :
Table category : supprimer l’index (en double) category_id_UNIQUE.
Table driver_price : faire passer price_id à la fin de la liste des attributs de la clé primaire. En conséquence l’index fk_driver_price_price1_idx refait surface et l’index fk_driver_price_driver_category1_idx disparaît :
Table CREATE TABLE driver_price (
price_id INT NOT NULL,
driver_id INT NOT NULL,
category_id INT NOT NULL,
PRIMARY KEY (driver_id, category_id, price_id),
CONSTRAINT driver_price_price_fk
FOREIGN KEY (price_id)
REFERENCES price (price_id)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT driver_price_driver_category_fk
FOREIGN KEY (driver_id, category_id)
REFERENCES driver_category (driver_id, category_id)
ON DELETE NO ACTION
ON UPDATE NO ACTION
, INDEX fk_driver_price_price1_idx (price_id ASC)
) ;
Table price_place : supprimer l’index price_place_place_fk_idx et mettre en œuvre l’index fk_price_place_category_price_fk_idx :
CREATE TABLE price_place (
price_id INT NOT NULL,
category_id INT NOT NULL,
place_id INT NOT NULL,
CONSTRAINT price_place_pk PRIMARY KEY (place_id, category_id, price_id),
CONSTRAINT price_place_price_fk FOREIGN KEY (category_id, price_id)
REFERENCES price (category_id, price_id),
CONSTRAINT price_place_place_fk FOREIGN KEY (place_id)
REFERENCES place (place_id)
, INDEX fk_price_place_category_price_fk_idx (category_id, price_id)
) ;
Table region : supprimer l’index fk_region_region_departement1_idx
Table driver_language supprimer l'index fk_driver_language_driver1_idx
Table commission_payment : supprimer l’index redondant commission_payment_id_UNIQUE.
Table disposal_booking : ajuster au mieux la taille des attributs. Permuter les attributs dans la clé primaire qui devient {client_id, id_disposal_booking} ; supprimer l’index fk_disposal_booking_client1_idx.
Table transfer_booking : ajuster au mieux la taille des attributs. Permuter les attributs dans la clé primaire qui devient {client_id, id_transfer_booking} ; supprimer l’index fk_transfer_booking_client1_idx.
Table promo : définir un index UNIQUE pour la clé alternative {promo_code} ; supprimer l'index promo_id_UNIQUE.
Table client_promo : permuter les attributs de la clé primaire ; supprimer l'index fk_client_promo_client1_idx.
Table client_promo_transfer_booking : clé primaire et clés étrangères à remettre à l’endroit :
CREATE TABLE client_promo_transfer_booking (
client_id INT NOT NULL,
promo_id INT NOT NULL,
id_transfer_booking INT NOT NULL,
PRIMARY KEY (client_id, promo_id),
CONSTRAINT client_promo_transfer_booking_client_promo_FK
FOREIGN KEY (client_id, promo_id)
REFERENCES client_promo (client_id, promo_id)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT client_promo_transfer_booking_transfer_booking_fk
FOREIGN KEY (client_id, id_transfer_booking)
REFERENCES transfer_booking (client_id, id_transfer_booking)
ON DELETE CASCADE
ON UPDATE NO ACTION
) ;
TABLE driver_payment revue :
CREATE TABLE driver_payment
(
id_payment_onboard INT NOT NULL AUTO_INCREMENT,
driver_id INT NOT NULL,
card_onboard TINYINT(1) NOT NULL,
vat_rate TINYINT(2) NOT NULL,
PRIMARY KEY (driver_id, id_payment_onboard),
INDEX fk_driver_payment_driver1_idx (driver_id ASC),
UNIQUE INDEX id_payment_onboard_UNIQUE (id_payment_onboard ASC),
CONSTRAINT fk_driver_payment_driver1
FOREIGN KEY (driver_id)
REFERENCES driver (driver_id)
ON DELETE CASCADE
ON UPDATE NO ACTION
) ;
J’en suis là...
Partager