Commentaires

Envoyé par f-leb

Le théorème de De Morgan :



Avec la présence du null, le théorème n'est plus vérifié

Eh oui, c'est toute la logique qui change avec le marqueur "null", ce qui milite grandement en défaveur des colonnes nullables

Envoyé par CinePhil

Pourquoi n'as-tu pas mis les cas 0 / null dans ta table de décision ?

0/null se comporte comme 1/null, d'où la simplification

Le théorème de De Morgan :



Avec la présence du null, le théorème n'est plus vérifié

1 OR null n'est pas null, le piège...

Pourquoi n'as-tu pas mis les cas 0 / null dans ta table de décision ?

Référence croisée avec le post de Séb. car c'est le même sujet :
https://www.developpez.net/forums/bl...es-5-methodes/

Je viens de me rappeler d'un chose dans ce que vous dite. Entre le faite de mettre une étoile ou nom de champ dans le count dans SQL Server.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9

CREATE TABLE #matable(nom varchar(10))
go
insert into #matable (nom)values ('Diriz'),('Colombo'),(null)--nom de mes greffiers 


select count(*) from #matable 
select count(nom) from #matable

Le premier résultat va retourne 3, le second 2 car le count va retourner que les valeurs non null

Envoyé par berceker united

Ce qu'il se passe dans la tête de certain aujourd'hui c'est que COUNT(*) = COUNT(champ1,champ2,champ3,champ4,...).

Quelques précisions :

• à ma connaissance, seuls MySQL et MariaDB acceptent une liste de colonnes dans la fonction COUNT()
  pour les autres SGBD, COUNT() s'applique soit avec *, soit avec un nom de colonne unique ;
• comme par défaut, c'est le paramètre ALL qui s'applique, utiliser SELECT COUNT(*) ou SELECT COUNT(Colonne1) produit le même résultat. En l'occurrence le nombre de lignes dans la table.
  Si par contre on utilise le paramètre DISTINCT, alors SELECT COUNT(*) et SELECT COUNT(DISTINCT Colonne1) peuvent évidemment produire un résultat différent, si Colonne1 présente la même valeur sur plusieurs lignes ;
• le paramètre DISTINCT n'est pas applicable avec (*) ;
• parler de "champs" est un abus de langage. Dans une table d'un SGBD relationnel, il n'y a pas de champs, il y a des colonnes. Les champs sont les zones d'un formulaire ou d'un état.

Très bon article, il faut une suite.
Dommage qu'il n'a pas été développé le cas du SELECT COUNT(*).
J'ai entendu tellement de chose sur ça. En gros, c'est issu d'un bug de l'époque napoléonienne (c'est une blague hein). Le moyens de contourner le problème était de faire SELECT COUNT(1), corrigé depuis et c'est resté dans les têtes jusqu'à aujourd'hui sans vraiment savoir pourquoi.
Ce qu'il se passe dans la tête de certain aujourd'hui c'est que COUNT(*) = COUNT(champ1,champ2,champ3,champ4,...). Je fais quand même confiance aux personnes développant les moteurs SQL qu'ils ne font pas cela.

Quand j'en parle aujourd'hui en prouvant par A+B ça reste encore sceptique "ouais... mais... bon.... voila .... c'est pas optimisé". Explique moi ce qu'il se passe derrière un count(*) ?
Pour embêter mes collègues je faisais exprès de mettre COUNT(8) => "ouais... mais... bon.... voila .... c'est pas optimisé..."

Souvent, par mimétisme nous codons sans trop se poser des questions du pourquoi.

Envoyé par wchris

Il y a d'autres cas où l'on peux s'en servir, par exemple dans le cas de requêtes imbriquées

Select * from (
Select Lbl1 "REFERENCE", val1 "VALEUR" from TABLEITEM1 where TI1TYPE='A'
UNION
Select Lbl2, val2 from TABLEITEM2 where TI1TYPE IN ('B', 'D')
)
where VALEUR between 50 and 200;

Dans ce cas il n'y a aucun impact sur le nombre de colonnes renvoyées ni les jointures et pourtant on a utilisé *

En effet, mais le SELECT * s'applique ici à une liste fermée de colonnes définie par la requête imbriquée, on en revient donc à la préconisation que j'ai formulée

Tout à fait d'accord avec le SELECT * à n'utiliser que pour de l'exploration ou un test d'existence.

Je me l'autorise également dans un cadre très contrôlé, où la requête maîtrise les colonnes, et pour éviter de la redite.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
WITH dataset (col1, col2, col3) AS (
    SELECT ALL col1, col2, col1 + col2
    FROM my_table
)
SELECT ALL *
FROM dataset;

J'ai déjà été confronté à des SELECT * qui ont dégradé un applicatif le jour où quelqu'un a eu la bonne idée d'ajouter une colonne BLOB contenant le binaire d'un e-mail. Les SELECT * ont généré beaucoup de trafic inutile et ont sensiblement impacté les perfs.

Il y a d'autres cas où l'on peux s'en servir, par exemple dans le cas de requêtes imbriquées

Select * from (
Select Lbl1 "REFERENCE", val1 "VALEUR" from TABLEITEM1 where TI1TYPE='A'
UNION
Select Lbl2, val2 from TABLEITEM2 where TI1TYPE IN ('B', 'D')
)
where VALEUR between 50 and 200;

Dans ce cas il n'y a aucun impact sur le nombre de colonnes renvoyées ni les jointures et pourtant on a utilisé *

PS je ne sais pas si l'exemple fonctionne je ne l'ai pas testé, c'est juste une illustration

Ca fait plaisir de lire une telle chose.

Il y a beaucoup de monde qui devrait lire ça, y compris certaines personnes qui se prétendent expert sql.

Envoyé par sanderbe

Votre article fait penser à la fonction "insert into" de MySQL . Quand on insert automatique un fichier plat, csv, txt ... l'autoincrement peut littéralement créer des "trous" dans la raquette de numérotation .

Cela dépend du paramétrage de MySQL, voir https://dev.mysql.com/doc/refman/8.0...-handling.html

Envoyé par Eric80

[...]
Mais est ce tjs pertinent de mettre des numéro comme IDENTITY donc comme PK et FK ?
Il me semblait que mettre des GUID était bcp plus tranquille et était devenue la norme: les avantages et inconvénient [...]

Ce n'est pas le sujet de ce blog, je n'y répondrai donc pas en détail ici, mais c'est le plus souvent une mauvaise idée.
Je vous recommande la lecture de ce billet de Frédéric Brouard sur cette question :
https://blog.developpez.com/sqlpro/p...ent_le_verdict

Comme dit, je suis un peu out dans le design des bases SQL, passée à du stockage noSQL depuis.
Mais est ce tjs pertinent de mettre des numéro comme IDENTITY donc comme PK et FK ?
Il me semblait que mettre des GUID était bcp plus tranquille et était devenue la norme: les avantages et inconvénient (essentiellement performance) sont rappelés ici: https://dba.stackexchange.com/questi...-a-primary-key et https://stackoverflow.com/questions/...s-int-identity
int semble tjs préféré par bcp, mais certains soulignent aussi d autres pb.

J imagine que Int garde du sens pour du code métier assez "proche" de la DB, mais que ceux qui utilisent des ORM et des requètes générées ou distribuées seraient mieux servis par des GUID.

Envoyé par sevyc64

je passe la PK en bitint, ainsi que les 15 FK qui la référence, et évidement tout le code métier derrière qui est lié plus ou moins directement à ces colonnes (en en oubliant forcément au passage).

tu touches là un autre pb. AMHA, le code métier ne devrait PAS dépendre du type des PK et FK!

Les ORM font généralement un bon boulot d abstraction à ce niveau.
Par ex, sur le EntityFramework de MS, la dernière fois que j ai touché à un gros projet métier l utilisant (bon il y a 10 ans...), les FK étaient définies par des relations: nulle trace de int out bigint dans le code métier!
edit: ou plutot si, il y a une trace des ID int dans le Entity DataModel, mais celui ci peut etre regénéré en qques clics après modif du type, sans que cela change le reste du code, si le code s'est bien gardé de travailler avec les propriétés xxxID définies en Int32.
donc oui, cela impose qd meme un redéploiement du code métier, ce qui peut etre bcp plus complexe que le coup de scalpel dans la DB.
Mais avec le coup de scalpel, il faut ensuite prier que les ID supprimés et réutilisés ne créent pas des bugs + tard (un truc bien codé ne devrait PAS tomber là dedans, mais qui sait...). Et aussi que ces IDs ne soient pas stockés dans des logs ou je ne sais quoi qui pourraient créer de la confusion avec la nouvelle entité une fois l ID réutilisé...
Bref, à moyen terme, le coût de redéploiement du code métier est peut être moins pire que de jouer aux sorciers dans la DB!

ATTENTION : si la contrainte d'unicité n'est pas supprimée, les SGBDR MySQL et PostGreSQL sont dans l'incapacité de mettre à jour la colonne, contrairement à IBM DB2, Oracle Database ou Microsoft SQL Server, parce qu'ils ne fonctionnent pas de manière ensembliste selon des règles de Codd et en particulier les règles 7 et 12...

Pour PostGreSQL une solution de contournement que je trouve horrible est de prévoir une contrainte déferrable (aussi faut-il l'avoir pensée au niveau de la modélisation avant d'avoir le problème). Pour MySQL seule solution supprimer la contrainte d'IR de la FOREIGN KEY et la remettre après (un cierge est bienvenu !).

Pour les colonnes pourvues de la propriété IDENTITY : cette propriété empêche l'UPDATE... Il faut alors supprimer la propriété IDENTITY de la colonne... C'est pas une mince affaire !

A +

Bonjour

Excellent !

A cela, j'ajouterai qu'une partie du travail des DBA devrait être consacrée à la surveillance de ces Identifiants.

Bonsoir

Votre article fait penser à la fonction "insert into" de MySQL . Quand on insert automatique un fichier plat, csv, txt ... l'autoincrement peut littéralement créer des "trous" dans la raquette de numérotation .