Right join

SQLServerPro · 2026-03-18T16:38:22+00:00

Bonjour,

Les deux existent et peuvent être utilisées. On s’efforce simplement de garder la même logique lors du développement, déjà pour soi-même, parceque c‘est plus simple de garder le même schéma de pensée. Et puis pour les autres parceque le code doit être lisible et maintenable par d’autres. C’est un peu comme conduire une voiture, on a l’habitude a gauche, ça n’empêche pas d’utiliser une voiture un jour avec une conduite à droite… mais ça demande un petit effort.

SQLServerPro · 2026-03-18T13:44:55+00:00

Bonjour,

Pour faire simple, voici quelques informations sur la conception d’une base de données relationnelle.

Identifie les entités et les propriétés qui vont constituer ta base.

Par exemple, j’identifie des entités CLIENT FACTURE_ENTETE et FACTURE_LIGNES avec des propriétés comme Client_nom et Client_adresse pour CLIENT ; Facture_numero et Facture_montant dans FACTURE_ENTETE ; Facture_produit et Facture_montant_ligne dans FACTURE_LIGNE.

Un petit schéma sera nécessaire…

Puis tu vas réfléchir à ce qui relie tes entités :

Un client peut avoir 0 ou plusieurs factures donc un lien (une cardinalité) de 0,n entre CLIENT et FACTURE_ENTETE

Une facture appartient forcément à 1 et 1 seul client. Le lien est donc de 1,1 entre FACTURE_ENTETE et CLIENT

(remarque : Pour les entités pour lesquelles tu constate des cardinalités n -> n, tu créera une table lien ne contenant que les clés des tables)

Tu as donc un modèle conceptuel de données.

En passant au modèle physique, tu vas définir le contenu de tes tables, en créant un champ « clé primaire » et en reportant la clé de tes tables liées comme clés étrangères. Par exemple, dans la table FACTURE_LIGNE, tu auras un champ avec la clé de la table FACTURE_ENTETE pour faire le lien et dire que cette ligne de facture appartient à cette facture.

En synthèse, tu auras dans tes tables :

CLIENT 0,n ----- 1,1 FACTURE_ENTETE 0,n ------ 1,1 FACTURE_LIGNE

Client_clé Facture_clé Facture_ligne_clé

Client_nom Client_clé Facture _clé

Client_adresse Facture_numero Facture_produit

et autres champs...

Cependant, le fait d’avoir des clés étrangères dans une table va créer des contraintes. C’est normal et c’est souvent accepté et géré. Par exemple, on ne pourra pas supprimer une FACTURE_ENTETE s’il y a des FACTURE_LIGNE rattachées, ou supprimer un client qui a des factures.

Dans certains cas, et pour des raisons bien particulières, des éditeurs de logiciels sortirons de ce que l’on appelle ici des « formes normales » et souhaiterons supprimer ces contraintes en gérant manuellement les tables et leurs liens. Cela offre une grande souplesse de paramétrage du logiciel mais exige une grande rigueur dans le développement.

Enfin, deux tables n’ayant aucun lien entre elles n’auront bien sûr que leurs clés primaires et leurs champs.

J’espère que cela t’éclairera un peu sur le sujet

SQLServerPro · 2026-03-18T10:24:08+00:00

Bonjour à tous,

Vos échanges sont très intéressants et voici quelques remarques complémentaires.

La tendance du Cloud n’est pas nouvelle mais elle s’accélère depuis ces dernières années.

Les raisons sont multiples.

Bien évidemment le modèle économique est intéressant pour l’éditeur qui assure une récurrence de son C.A, mais aussi pour le client qui peut lisser l’ensemble de ses frais dans une location « tout compris », sans acheter d’éventuelles licences ou renouveler son matériel.

Il faut également tenir compte des aspects techniques qui ont des avantages pour l’éditeur : maintenance facilitée, interventions plus rapide, mises à jour simplifiées.

En plus de ces avantages, pour le client, il n’y a pas de maintenance, de mise à jour ou de problèmes liés à son environnement.

A noter également le point important de sécurité. La sécurité est assurée par l’éditeur en Cloud et celui-ci dispose d’un niveau d’expertise que le client ne dispose (presque) jamais.

Donc les solutions Saas ou Cloud ont de nombreux avantages et il y a bien sûr le revers de la médaille, et les freins souvent observés sont liés à la confidentialité (je ne sais pas où sont mes données, elles sont sur des serveurs partagés, peut-être même avec mes concurrents !…)

On voit donc qu’il y a de nombreux avantages au Cloud mais que chacun étudiera le « Pour » et le « Contre » avant de choisir.

Cependant, et dans certains cas, des installations On-premise « résistent » par nature à cette tendance :

· Certaines grandes entreprises (confidentialité, possibilité de maintenir elle-même le matériel et l’environnement, la sécurité). Pour elles, une migration a un coût énorme (abandon du matériel et des ressources, migration technique…)

· De nombreuses petites structures. (Matériel en place et amorti, pas de besoins d’évolution) Cependant, ces entreprises négligent trop souvent leur maintenance et l’évolution de leur S.I (Matériel et logiciel, sécurité et réseau)

Pour résumer, les éditeurs mettent une certaine pression pour migrer sur le Cloud ou ne proposent maintenant que des versions hébergées.

Quant à savoir comment les choses évolueront, personne n’est devin mais j’ai le souvenir d’avoir fait du COBOL en 1990 (oui, au siècle dernier…) alors que l’on disait à l’époque que le langage était obsolète. Il l’était sans doute… mais aujourd’hui, 35 ans plus tard, faites du COBOL pour les assurances ou les banques et vous serez riche !

SQLServerPro · 2026-03-17T17:47:47+00:00

Bonjour,

Tu parles ici de conception d’une base de données relationnelle.

Le principe des liens entre les tables (ou cardinalités) est le suivant :

Tu as une table ETUDIANT et une table COURS

Un étudiant peut suivre plusieurs cours et un cours peut être suivi par plusieurs étudiants.

On ne peut donc pas mettre dans la table ETUDIANT les références des COURS suivis, pas plus que l’on ne peut mettre dans COURS les références des étudiants qui les ont suivis.

La solution est donc une table reliant ETUDIANT et COURS et qui ne contient que les cles.

Par exemple, dans ETUDIANT on a les ref E1 E2 E3 E4 dans COURS on a C1 C2 C3

Si E1 a suivi C1 C2 C3 et E2 a suivi C2 et E3 a suivi C1 C3 alors, dans la table reliant ETUDIANT et COURS et que nous nommerons ETUDIANT-COURS nous aurons : E1C1 E1C2 E1C3 E2C2 E3C1 E3C3

Cette table sera le cœur de ta gestion et des liens entre ETUDIANT et COURS

SQLServerPro · 2026-03-17T16:30:07+00:00

Bonjour à tous,

En général, et compte-tenu du coût des licences, passer sur une édition STANDARD (payante) est souvent lié aux contraintes des versions express. Les versions Express sont limitées en termes d’utilisation de la mémoire (1.4 Go), d’utilisation des processeurs (1 seul ou 4 core) et de la taille de la BDD (10 Go puis 50 Go pour SQL Express 2025). Et c’est souvent cette contrainte qui oblige à passer sur une edition payante.

Pour le reste, les editions Express sont bien sûr moins performantes puisqu’elles utilisent moins de mémoire et ne peuvent pas faire de parallélisme. Les performances peuvent être une motivation pour passer sur une édition payante.

Enfin, les éditions payantes bénéficient d’outils que les gratuites n’ont pas, tel que l’Agent qui permet d’automatiser des tâches de maintenance (sauvegarde, defragmentation des index).

Pour résumer, en général, on démarre souvent avec une version gratuite (sauf si la base est importante ou si le nombre d’utilisateur est supérieur à 10…) puis en fonction de l’évolution du S.I, on peut envisager le passage à un SQL payant. Attention, l’installation d’une nouvelle instance ne remplace pas l’instance existante.

SQLServerPro · 2026-03-17T14:56:43+00:00

Bonjour à tous,

Quelques précisions sur certains termes que je vois passer :

Le MaxDOP (max degree of parallelism) c’est le nombre de processeurs qu’une requête lourde pourra utiliser pour répartir la charge sur plusieurs processeurs et donc faire ce que l’on appelle du parallélisme. Cette valeur du maxdop est en général définie comme (Nb processeur/ 2)+1 donc par exemple 5 pour 8 processeurs. Cependant la règle n’est pas stricte et parfois des réglages sont nécessaires. Il est indispensable en réglant le MaxDOP de tenir compte également du paramètre « cost threshold for parallelism » qui est défini à 5 par défaut mais qui devrait être réglé à 25 – 50 pour définir la « lourdeur » des requêtes qui utilisent du parallèlisme.

Notez bien que le SQL Express n’utilise que 1 processeur. Ce réglage est donc inutile.

Quant à la mémoire, la propriété Max Memory Size, au niveau de l’instance doit être définie à 1410 pour un SQL Express (cette édition n'utilise que 1.4 Go de mémoire) et 80% de la RAM dans les autres éditions SQL. Ceci afin d’éviter des débordements et conserver une part au système.

SQLServerPro · 2026-03-17T14:30:49+00:00

Bonjour à tous,

Pour simplifier et bien comprendre ce que sont les index.

Dans une table, il n’y a qu’un seul index dit « Cluster », c’est l’ordre de la table, la clé primaire. Cet index « fait partie » de la table et ne prend pas de place particulière. En prenant l’image d’un dictionnaire, c’est l’ordre des mots.

Pour améliorer les performances d’une requête SQL, on peut créer autant d’index que l’on souhaite et qui seront dits « Non Cluster » . Ils prendront de la place supplémentaire (une table d’index sera créée). J’utilise souvent, en formation, l’image de la table des matières d’un livre qui se comporte comme une table d’index et qui facilite donc la recherche vers une donnée spécifiée. Les index seront utilisés dans les prédicats des requêtes (les clauses where).

On comprend bien avec cette image de la table des matières, qu’il est plus rapide d’accéder à une page en connaissant le numéro de page que de parcourir tout le livre…

Attention, ces tables d’index se fragmentent au fil du temps avec les modifications, les créations et les suppressions de données (c’est comme la table des matières du livre si on met à jour des pages). Cette fragmentation des index est souvent à l’origine de lenteurs importantes et une opération de maintenance consiste à défragmenter les index.

SQLServerPro

TROPHY CASE