Discussion :

[F1TRN]

Bonjour,

Je rencontre un pb (de syntaxe semble t-il) à la création d'une table en mariaDB (pas de pb à la création de la database).
Voici mon code:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
database = """CREATE DATABASE IF NOT EXISTS db_solardata;"""
 
t_Solar_Data = """
        CREATE TABLE IF NOT EXISTS t_Solar_Data (
        id_solar_data INT NOT NULL AUTO_INCREMENT,
        updated DATETIME NOT NUL,
        solarflux SMALLINT DEFAULT NUL,
        aindex SMALLINT DEFAULT NUL,
        kindex SMALLINT DEFAULT NUL,
        kindexnt VARCHAR DEFAULT NUL,
        xray VARCHAR DEFAULT NUL,
        sunspots SMALLINT DEFAULT NUL,
        heliumline FLOAT DEFAULT NUL,
        protonflux SMALLINT DEFAULT NUL,
        electonflux SMALLINT DEFAULT NUL,
        aurora SMALLINT DEFAULT NUL,
        normalization FLOAT DEFAULT NUL,
        latdegree FLOAT DEFAULT NUL,
        solarwind FLOAT DEFAULT NUL,
        magneticfield FLOAT DEFAULT NUL,
        geomagfield VARCHAR DEFAULT NUL,
        signalnoise VARCHAR DEFAULT NUL,
        fof2 FLOAT DEFAULT NUL,
        muffactor FLOAT DEFAULT NUL,
        muf FLOAT DEFAULT NUL,
        PRIMARY KEY(id_solar_data) ); """
 
try:
    conn =  mysql.connector.connect(host="127.0.0.1",
                                   user="root", password="raspberry")
    cursor = conn.cursor()
    cursor.execute(database)
    cursor.execute("""use db_solardata;""")
    cursor.execute(t_Solar_Data)
    cursor.execute(t_calculatedconditions)
    cursor.execute(t_calculatedvhfconditions)
except mysql.connector.errors.InterfaceError as e:
    print("Error %d: %s" % (e.args[0], e.args[1]))
    sys.exit(1)
finally:
    # On ferme la connexion
    if conn:
        conn.close()
        print('The database and the tables have been correctly created.')

L'erreur est :

Code :

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

1
2
3
4
5
 
mysql.connector.errors.ProgrammingError: 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'NUL,
        solarflux SMALLINT DEFAULT NUL,
        aindex SMALLINT DEFAULT NUL,
        kindex S...' at line 3

Mais je ne parviens à m'en sortir.

[Arioch]

Vous avez beaucoup de NUL avec un seul L dans votre requête.

[F1TRN]

Merci Arioch, je n'avais même pas vus mes fautes de frappe (je suis NUL = NULL )

[Sve@r]

Bonjour

cursor.execute("""use db_solardata;""")

Je ne suis pas certain que ce soit une bonne pratique. Je pense que tu devrais fermer la connection pour en ouvrir une nouvelle sur la bdd créée.
Accessoirement les triples quotes ne sont pas utiles pour de simples strings.

Et (autre façon de faire), personnellement quand j'ai un projet avec bdd, j'inscris la création bdd dans un fichier sql que je joue (ou rejoue si je veux tout réinitialiser) directement. Mes codes Pythons partent du principe que la bdd existe et si elle n'existe pas, l'indiquent au début du programme mais je ne m'embête pas à la leur faire créer.

[wiztricks]

Mes codes Pythons partent du principe que la bdd existe et si elle n'existe pas, l'indiquent au début du programme mais je ne m'embête pas à la leur faire créer.

C'est pour ça qu'on a des "CREATE TABLE IF NOT EXISTS..."

- W

[F1TRN]

Merci à tous... J'appends avec vous, même si je ne comprends pas toujours tous.

Maintenant je veux ajouter deux autres tables et et les lier à la première. Dites moi si je me trompe, mais d'après ce que je comprends dans les différentes lectures ça doit ressemble à une truc comme ça:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
# Table 1
t_1 = """
        CREATE TABLE IF NOT EXISTS t_1 (
        ID INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
        ID_T_2 INT UNSIGNED NOT NULL,
        ID_T_3 INT UNSIGNED NOT NULL,
        .../...
        FOREIGN KEY (ID_T_2) REFERENCES nom_database.t_2(id_t2),
        FOREIGN KEY (ID_T_3) REFERENCES nom_database.t_3(id_t3)
);"""
# Table2
t_2 = """
        CREATE TABLE IF NOT EXISTS t_2 (
        id_t2 INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
        .../...
);"""
# Table3
t_3 = """
       CREATE TABLE IF NOT EXISTS t_3(
       id_t3 INT UNSIGNED NOT NULL PRIMARY KEY AUTO INCREMENT,
       .../...
);"""

Mais j'obtiens l'erreur:

Code :

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

Can't create table `db_solardata`.`t_Solar_Data` (errno: 150 "Foreign key constraint is incorrectly formed")

[Arioch]

Code :

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

id_t3 INT UNSIGNED NOT NULL PRIMARY KEY AUTO INCREMENT,

Pas d'underscore à AUTO INCREMENT ici ?

[wiztricks]

Salut,

Mais j'obtiens l'erreur:

Code :

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

Can't create table `db_solardata`.`t_Solar_Data` (errno: 150 "Foreign key constraint is incorrectly formed")

C'est une erreur dans votre SQL qui est un mini-langage qui n'a rien à voir avec Python (et qui a sa propre rubrique (SGDB) voire mariadb.

J'appends avec vous, même si je ne comprends pas toujours tous.

Vous codez en tapant sur le clavier en espérant que çà tombe en marche sans message d'erreur. Il faut vous former avant... histoire d'avoir réfléchi à quoi coder et comment pour avoir des résultats certains plutôt que n'importe quoi.

- W

[F1TRN]

Vous codez en tapant sur le clavier en espérant que çà tombe en marche sans message d'erreur. Il faut vous former avant... histoire d'avoir réfléchi à quoi coder et comment pour avoir des résultats certains plutôt que n'importe quoi.
- W

C'est ce que je fait, je lis, puis j'essaye d'appliquer, mais sur le web y-a tellement de choses bonnes et non bonnes que parfois.

[F1TRN]

Code :

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

id_t3 INT UNSIGNED NOT NULL PRIMARY KEY AUTO INCREMENT,

Pas d'underscore à AUTO INCREMENT ici ?

Arioch, je ne comprends pas pourquoi car d'après le wiki MariaDB AUTO_INCREMENT à un underscore.
Et pourquoi uniquement sur t_3.id_t3 ?

Si je le retire de t_2 et de t_3 j'ai tjrs la même erreur de syntaxe.

Code :

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

(errno: 150 "Foreign key constraint is incorrectly formed")

[Sve@r]

C'est pour ça qu'on a des "CREATE TABLE IF NOT EXISTS..."

Ouais super. Mais comme je parle de la bdd elle-même et non de ses tables (bien entendu, le script qui crée la bdd crée aussi les tables qui vont avec)
De plus si je pars du principe que la bdd (et ses tables) existent déjà, comme je l'ai dit je ne vois pas l'utilité de m'embêter à les faire créer par Python, avec ou sans la clause "if not exists"....

Maintenant je veux ajouter deux autres tables et et les lier à la première. Dites moi si je me trompe, mais d'après ce que je comprends dans les différentes lectures ça doit ressemble à une truc comme ça:

Ce n'est plus un souci Python mais un souci de syntaxe SQL. Tu aurais donc avantage à aller poster là-bas.
Ce que tu nommes "liaison" est appelé "contrainte d'intégrité". Comme son nom l'indique, ça permet à une bdd de rester intègre.
Imaginons par exemple dans un magasin une table "ref_modele" qui référence les modèles. Il y aura le modèle AX001 => robe légère, le modèle AY001 => pull-over etc etc.
Arrive ensuite la table des prix. Il y aura donc le prix AX001 - Coton - 55€ ; le prix AX001 - Laine - 90€ etc.
A cette contrainte, il faut indiquer quoi faire quand la référence disparait. Que faire donc si AX001 disparait du modèle. Là tu as plusieurs possibilités

• tu cascades la disparition sur les tables associées => tous les prix AX001 disparaissent aussi
• tu interdis la disparition => s'il y ne serait-ce qu'un seul prix AX001 alors tu ne peux pas supprimer le modèle AX001
• tu mets à NULL => si le modèle AX001 disparait, alors les prix deviennent NULL - Coton - 55€ ; NULL - Laine - 90€
• tu mets à défault (sous-entendu que la table des prix possède une valeur par défaut pour la colonne qui référence le modèle)
• tu demandes qu'il ne se passe rien => le modèle AX001 disparait, les lignes contenant le prix AX001 ne changent pas bien que AX001 ne soit plus référencé

Et tu as des choix équivalents en cas de modification. Si le modèle AX001 change pour BX001, alors tu peux cascader la modification, refuser la modification, ne rien faire, mettre à null ou mettre à défaut.
Donc quand tu crées ta contrainte, tu dois spécifier ce qui se passe sur "on update" et "on delete" (et MariaDB doit avoir une doc à ce sujet) et ça ça se réfléchit (et pire si tableA liée à tableB elle-même liée à tableC => les contraintes s'exponentialisent)

Voici par exemple un extrait d'une de mes bdd (mais je bosse sous Postgres et non MySQL donc la syntaxe a quelques différences) où j'associe des personnes avec un titre "M.", "Mme", "Mlle"

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
create table "_cat_titre" (
	"id_titre" smallint not null check ("id_titre" > 0),
	"sigle" character varying(10) not null check ("sigle" not similar to ' *'),
	"libelle" character varying(20) not null check ("libelle" not similar to ' *'),
	primary key ("id_titre")
) with (oids=false);
 
insert into "_cat_titre" values (1, 'M.', 'Monsieur');
insert into "_cat_titre" values (2, 'Mme', 'Madame');
insert into "_cat_titre" values (3, 'Mlle', 'Mademoiselle');
insert into "_cat_titre" values (4, 'Sté', 'Société');
 
create table "personne" (
	"id_personne" integer not null default nextval('"seq_personne_id"') check ("id_personne" > 0),
	"nom" character varying(40) not null check ("nom" not similar to ' *'),
	"prenom" character varying(30) not null check ("prenom" not similar to ' *'),
	"comment" text default null check ("comment" not similar to ' *'),
	"date_creation" date not null check ("date_creation" <= ('today'::text)::date) default ('today'::text)::date,
	"id_titre" smallint not null,
	constraint "fk_titre" foreign key ("id_titre")
		references "_cat_titre" ("id_titre") match full
		on update cascade on delete restrict,
	primary key ("id_personne")
) with (oids=false);

Accessoirement, au lieu de passer par Python, passe directement par sql pour faire tes tests sql, ça évitera un intermédiaire et les soucis qui peuvent aller avec. Et si tu utilises un outil d'administration graphique (exemple phpMyAdmin) alors tu peux créer ta bdd, tes tables et leurs contraintes via clic/drag/drop à la souris et regarder le sql que ça génère.

[wiztricks]

De plus si je pars du principe que la bdd (et ses tables) existent déjà, comme je l'ai dit je ne vois pas l'utilité de m'embêter à les faire créer par Python, avec ou sans la clause "if not exists"....

C'est une opinion qui comme toute opinion doit être respectée... cependant, c'est le développeur qui en dernier recours décide en fonction de la situation et du contexte.

Il est clair que si on doit aller modifier une base de donnée administrée, il faudra pousser le SQL aux administrateurs de la BDD qui pourront vérifier que çà fait bien ce qu'on attend (les specs) avant de les exécuter.

Maintenant, si je dois créer une petite base de donnée sqlite associée à un utilisateur ou une application les CREATE IF seront tout a fait acceptables.

note: lorsque je code autre chose que des exemples, j'utilise souvent SQLAlchemy et le CREATE IF est utilisé par défaut. comme quoi une opinion n'est pas la réalité.

- W

[F1TRN]

Sve@r

Oui je vais poser la question sur le forum mySQL.

[F1TRN]

Sve@r

Oui je vais poser la question sur le forum mySQL.

Chose faite et la réponse n'a pas tardée.
Solution:
Ordre de création des tables.

Du coups:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| db_solardata       |
| information_schema |
| mysql              |
| performance_schema |
+--------------------+
4 rows in set (0.001 sec)
 
MariaDB [(none)]> use db_solardata;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
 
Database changed
MariaDB [db_solardata]> show tables;
+---------------------------+
| Tables_in_db_solardata    |
+---------------------------+
| t_Solar_Data              |
| t_calculatedconditions    |
| t_calculatedvhfconditions |
+---------------------------+
3 rows in set (0.001 sec)
 
MariaDB [db_solardata]>

Alors maintenant je vais passer au INSERT JOIN et SELECT JOIN

Vas y avoir du sport Je crois que je vais beaucoup lire sur le sujet.

[Sve@r]

Alors maintenant je vais passer au INSERT JOIN et SELECT JOIN

Vas y avoir du sport Je crois que je vais beaucoup lire sur le sujet.

insert join je n'en ai jamais fait. Je vois à quoi cela devrait servir mais je n'en ai jamais eu l'utilité. select join oui ça c'est utile. Ca permet de récupérer les informations de la table de base ainsi que celles associées dans la table liée.
Si on reprend mon exemple, ça permet de récupérer les personnes de ma table "personne" ainsi que leur titre "M.", "Mme", "Mlle" => select personne.*, _cat_titre.sigle from personne inner join _cat_titre on _cat_titre.id_titre=personne.id_titre where personne.colonneX=valeur_precise.

Après il y a la distinction "inner join" et "outer join". Pour comprendre la différence, il faut essayer de comprendre comment on doit réagir quand l'info n'y est pas. Parce que "pas d'info" ne signifie pas "info pas correcte"
Imaginons des personnes et leur ville de naissance. Toutefois pour certaines personnes la ville n'est pas mentionnée (NULL). Et on veut les personnes nées à Lyon.
La question est "si la ville n'est pas indiquée, est-ce que cette personne doit quand-même ressortir (elle peut très bien être née à Lyon bien que ce ne soit pas mentionné) ou pas". Le premier cas correspond à un "outer join" et le second cas à un "inner join".
Si tu demandes les infos de la table maitre et des infos associés de la table liée, et que la table liée contient des trous, avec "inner join" tu n'auras que les infos de la table maitre qui ont une liaison et "outer join" tu auras aussi les infos de la table maitre sans liaison.
Et ensuite, en cas de "outer", il faut spécifier "left outer join" ou "right outer join", chaque spécification gérant le côté de liaison. Avec "left outer join" on a l'info de gauche (la table maitre) même si la table liée a un trou à ce niveau ; et avec "right outer join" on a l'info de droite (celle de la table liée) même si celle-ci n'a pas d'info maitre correspondante.

[F1TRN]

Ho la la attends je suis encore là. Pour le moment je ne fait que de comprendre légèrement ce que je lis depuis 3 jours.

Et là, je dois encore comprendre comment faire mes INSERT avec mes tuples qui ne sont pas formatés de la même manière:

Code :

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

solardata : [('source', 'N0NBH'), ('updated', '07 Apr 2022 1320 GMT'), ('solarflux', '117'), ('aindex', '8'), ('kindex', '4'), ('kindexnt', 'No Report'), ('xray', 'B5.0'), ('sunspots', '61'), ('heliumline', '132.1'), ('protonflux', '94'), ('electonflux', '1600'), ('aurora', '1'), ('normalization', '1.99'), ('latdegree', '67.5'), ('solarwind', '410.5'), ('magneticfield', '-3.0'), ('calculatedconditions', ''), ('calculatedvhfconditions', ''), ('geomagfield', 'ACTIVE'), ('signalnoise', 'S3-S4'), ('fof2', '5.25'), ('muffactor', '2.94'), ('muf', '15.43')]

Ici je dois récupérer les valeurs de source, updated, solarflux ... ce doit aller dans les champs de la 1er table

Code :

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

calculatedconditions : ['80m-40m, day, Poor', '30m-20m, day, Fair', '17m-15m, day, Fair', '12m-10m, day, Poor', '80m-40m, night, Fair', '30m-20m, night, Fair', '17m-15m, night, Fair', '12m-10m, night, Poor']

Ici je dois récupérer les valeurs de 80m-40m, day, Poor pour aller dans les champs de la 2eme table sans oublier que sont id doit aller dans la première table.

Code :

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

calculatedvhfconditions : ['vhf-aurora, northern_hemi, Band Closed', 'E-Skip, europe, Band Closed', 'E-Skip, north_america, Band Closed', 'E-Skip, europe_6m, Band Closed', 'E-Skip, europe_4m, Band Closed']

Ici comme au dessus mais pour la 3eme table sans oublier que son id vas dans la première.

Bref, j'ai encore des choses à apprendre et a faire.

[Sve@r]

Et là, je dois encore comprendre comment faire mes INSERT avec mes tuples qui ne sont pas formatés de la même manière:

Code :

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

solardata : [('source', 'N0NBH'), ('updated', '07 Apr 2022 1320 GMT'), ('solarflux', '117'), ('aindex', '8'), ('kindex', '4'), ('kindexnt', 'No Report'), ('xray', 'B5.0'), ('sunspots', '61'), ('heliumline', '132.1'), ('protonflux', '94'), ('electonflux', '1600'), ('aurora', '1'), ('normalization', '1.99'), ('latdegree', '67.5'), ('solarwind', '410.5'), ('magneticfield', '-3.0'), ('calculatedconditions', ''), ('calculatedvhfconditions', ''), ('geomagfield', 'ACTIVE'), ('signalnoise', 'S3-S4'), ('fof2', '5.25'), ('muffactor', '2.94'), ('muf', '15.43')]

Bah si, ça me semble formaté pareil (chaque tuple contenant 2 strings...)

Ici je dois récupérer les valeurs de source, updated, solarflux ...

Pas compliqué: on transforme la liste de tuples en dictionnaire (ddd=dict(solardata)) puis on peut récupérer l'info que l'on veut (print(ddd["source"])). De là à l'envoyer dans une string contenant un ordre insert...

[F1TRN]

Oui exactement ce que je veux faire puis un:

Code :

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

1
2
cur.executemany("INSERT INTO rehberim(names, phone, mobile, email, \
                     photo, address, note, date) VALUES({0}, {1}, {2}, {3}, {4}, {5}, {6}" .format (myTuple[1], myTuple[2], myTuple[3], myTuple[4], myTuple[5], myTuple[6], myTuple[7])

[dedalios]

si je reviens sur le code SQL erronée
hormis le problème de "NUL" il existe un problème avec les varchar dont la longueur n'est pas stipuler ce qui pose problème au fork de MySQL Mariam dB

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
CREATE TABLE IF NOT EXISTS t_Solar_Data(
    id_solar_data INT NOT NULL AUTO_INCREMENT,
    updated DATETIME NOT NULL,
    solarflux SMALLINT DEFAULT NULL,
    aindex SMALLINT DEFAULT NULL,
    kindex SMALLINT DEFAULT NULL,
    kindexnt VARCHAR(10) DEFAULT NULL ,
    xray  VARCHAR(10) DEFAULT NULL ,
    sunspots SMALLINT DEFAULT NULL,
    heliumline FLOAT DEFAULT NULL,
    protonflux SMALLINT DEFAULT NULL,
    electonflux SMALLINT DEFAULT NULL,
    aurora SMALLINT DEFAULT NULL,
    normalization FLOAT DEFAULT NULL,
    latdegree FLOAT DEFAULT NULL,
    solarwind FLOAT DEFAULT NULL,
    magneticfield FLOAT DEFAULT NULL,
    geomagfield  VARCHAR(10) DEFAULT NULL ,
    signalnoise  VARCHAR(10) DEFAULT NULL ,
    fof2 FLOAT DEFAULT NULL,
    muffactor FLOAT DEFAULT NULL,
    muf FLOAT DEFAULT NULL,
    PRIMARY KEY(id_solar_data)
) ENGINE = InnoDB

Il existe des outils d'aide a la gestion des bases de données . Par exemple phpMyAdmin qui permet d'accéder a une base MARIANDB (entre autre), ce type d'outil permet de prendre en charge une partie de la modélisation de la base de donnée mais c'est une solution de type interface web qui demande d'avoir un moteur d'interprétation du langage de programmation PHP .

Il existe aussi la solution d'un produit tel que DBeaver qui ce definie comme un Outil de base de données universel .
voila ce qu'il en dise sur leur serveur.
Outil de base de données multiplateforme gratuit pour les développeurs, les administrateurs de bases de données, les analystes et toutes les personnes qui ont besoin de travailler avec des bases de données. Prend en charge toutes les bases de données populaires : MySQL, PostgreSQL, SQLite, Oracle, DB2, SQL Server, Sybase, MS Access, Teradata, Firebird, Apache Hive, Phoenix, Presto, etc.

[wiztricks]

il existe un problème avec les varchar dont la longueur n'est pas stipuler ce qui pose problème au fork de MySQL Mariam dB

Le langage SQL n'est pas 100% compatible d'un SGDB à l'autre... c'est effectivement un soucis qu'on découvre assez rapidement lorsqu'on change de SGDB.

Plus tard, on découvrira peut être aussi que les moteurs se comportent différemment côté optimisations...

L'un dans l'autre, on conclura que changer de SGDB n'est pas quelque chose à envisager à la légère... Et que le spécialiste du SGDB X ne sera pas forcément à l'aise avec le SGDB Y.

- W