SQLiteManager et les clefs primaires

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : SQLiteManager et les clefs primaires

par Sékiltoyai » 05 août 2008, 15:56

Ah mais c'est sans compter sur la ligne de commande :P
http://www.sqlite.org/download.html
Et ya des binaires pour OS X (même si tu peux le compiler toi même :) )

par Louisss » 05 août 2008, 15:48

Merci pour ces infos Berzemus.

C'est dommage, sqliteadmin n'existe visiblement que sous Windows, et moi je bosse sous MacOS X. En tout cas, j'en reviens à la conclusion de tout à l'heure : si on choisi de bosser avec SQLiteManager, il faut connaître cet aspect un peu gênant et faire avec.

par Berzemus » 05 août 2008, 15:37

De mon expérience avec SQLITE et ce qu'on peut trouver comme "manager": a éviter.

Le mieux, c'est de créer, gérer et administrer la table directement en php, ou sinon, par un pont ODBC depuis DBVisualiser ou quelque chose comme ça.

Ou trouver un semblable à phpmyadmin mais pour sqlite. Car la principale différence entre sqlitemanager et phpmyadmin, c'est que mysql est un serveur de données en tant que tel, alors que pour ouvrir une db sqlite, le logiciel doit fournir sa propre implentation de sqlite, qui diffère quasi tout le temps. Mieux vaut donc utiliser celle de php5 directement.

Sinon, pour examiner et étudier mes db sqlite, j'utilise plutôt sqliteadmin, mais jamais pour agir sur les données ou apporter des changements.

par Louisss » 05 août 2008, 13:07

Hep hep, qui parle de clef primaire composite ? Ce n'est pas le problème que j'évoque (d'ailleurs, j'ai cru comprendre que SQLite ne permet pas les clefs primaires composées de plusieurs champs). Non, moi mon problème c'est juste de pouvoir changer la clef primaire d'une table : prendre un champ à la place d'un autre pour tenir ce rôle.

Donc, ce serait bien un bug d'après toi zeus ? Mais je suis vraiment très étonné que mon SQLiteManager soit buggé, car comme PHPMyAdmin, c'est une simple distribution d'un site Web que j'ouvre en local avec mon serveur Apache perso. Je serais très intéressé que quelqu'un puisse tester pour savoir si c'est un bug présent de façon générale dans SQLiteManager et qui sera (est ?) peut-être corrigé dans une nouvelle version, ou bien si c'est moi qui ai un problème non général. Pour info, j'utilise MAMP pour mes développements en PHP et c'est donc lui qui me fournit SQLiteManager en version 1.2.

De mon côté, j'ai essayé d'exécuter directement la requête de création de table dans une page PHP plutôt que dans SQLiteManager. Résultats :

Code : Tout sélectionner

CREATE TABLE test (Premier TINYINT, Second VARCHAR(50) PRIMARY KEY, Troisieme VARCHAR(50), Quatrieme DATE);
Cette requête me colle la clef primaire sur le champ "Premier".

Code : Tout sélectionner

CREATE TABLE test (Second VARCHAR(50) PRIMARY KEY, Premier TINYINT, Troisieme VARCHAR(50), Quatrieme DATE);
Cette requête me colle la clef primaire sur le champ "Second".

Donc, le problème ne vient visiblement pas de SQLiteManager, mais de l'interprétation de ma requête par SQLite lui-même.
Ma base est en version 2, et SQLite en version 2.8.17.

Il existe peut-être une version plus récente ?

Autre détail intéressant : j'ai fait un test sur un SQLiteManager mis à disposition en ligne à l'adresse : http://synd-mixte.rain.fr/sqlitemanager/
C'est exactement la même version que moi.
J'ai essayé de créer une table avec le troisième champ comme clef primaire : même résultat c'est le premier champ qui est retenu comme clef primaire. Le problème ne vient donc visiblement pas de chez moi, mais on dirait plutôt que c'est un bug de cette version de SQLite.
Alors si quelqu'un peut me dire où trouver une version plus récente qui corrige ce bug, ce serait génial, même si on est bien d'accord que ça n'a rien de fondamental.

par _activmik » 05 août 2008, 12:38

Je maitrise pas assez cette particularité pour débattre, je fais confiance à ton savoir :wink:

par zeus » 05 août 2008, 12:33

une clé primaire composite reste une clé primaire ...

par _activmik » 05 août 2008, 12:25

Quand elle se trouve sur plusieurs champ, ça devient une clé composite non ? Or il parle que de clé primaire... Bref ne jouons pas sur les mots, l'important c'est qu'il est trouvé une solution :wink:

par zeus » 05 août 2008, 12:15

_activmik, merci de ton implication, mais dans le cas présent, je pense que tu n'as pas saisie le problème ...

Louisss travaille avec SQLite, pas avec MySQL.
Ensuite, sache qu'il est possible de sortir des chemins tracés. J'ai eu à créer des tables sans clés primaires pour des besoins de performances et car l'unicité ne m'intéressait pas.
De plus, une clé primaire peut se trouver n'importe où dans la table, voir même sur plusieurs champs ;)

Sinon, pour toi Louisss, à part un bug dans ton logiciel, je ne vois pas ... est-ce que tu peux essayer avec un autre logiciel ?

par _activmik » 05 août 2008, 11:51

Perso j'utilise MySQL Query Browser, essaie le :wink:

par Louisss » 05 août 2008, 11:49

Ok, donc conclusion : l'ergonomie de SQLiteManager n'est pas top, voir tend un peu vers le bug, mais quand on le sait, il suffit d'en tenir compte.

par _activmik » 05 août 2008, 11:45

Pourquoi vouloir réinventer la poudre ?
Quand tu crée tes tables, ton premier champ sera ta clé primaire, car si tu suis une certaine logique c'est bien le champ le plus important de ta table.. Bref, ça c'est une chose, ensuite le fait que SQLlite te mette obligatoirement ton premier champ en PK et ce même si tu lui défini bien un autre, effectivement c'est emm****.

La solution : prendre en compte cet aspect et réfléchir avant de construire tes tables (passe par papier) :wink:

par Louisss » 05 août 2008, 11:24

it's not a bug, it's a feature !!

Peut-être que c'est pour bien les mettre en évidence ? de toute façon, qu'importe l'ordre des colonnes..
Oui, Berzemus, je suis bien d'accord que l'ordre des colonnes n'a pas d'importance, mais par contre, pouvoir définir celle qu'on veut comme clef primaire, ça, ça a un maximum d'importance. Je comprend l'idée que dans le classement des colonnes, SQLite préfère que la clef primaire soit en première position (encore que, si justement ça n'a aucune importance, à quoi ça sert ??? ), mais j'en conclu donc que si on se trompe par exemple dans le choix de la clef primaire d'une table, il faut donc changer l'ordre des colonnes pour mettre la bonne en première place (hyper pratique)... Et voici maintenant la question qui tue : comment fait-on pour changer l'ordre des colonnes dans SQLiteManager ? Ou dans SQLite tout court ???

D'autre part, je ne sais pas si vous avez bien compris de quoi je parle en fait, parce que quand je clique sur le petit bouton en forme de clef avec marqué "PK" dedans en face du champ "Troisieme" (que je veux donc mettre en clef primaire), SQLiteManager me génère la requête suivante :

Code : Tout sélectionner

CREATE TABLE test ( Premier VARCHAR ( 50 ) , Second TINYINT , Troisieme VARCHAR ( 50 ) PRIMARY KEY , Quatrieme DATE ) ;
Logique ce code, il recrée la table en appliquant la clef primaire là où je le lui demande. Mais à l'exécution, le résultat c'est que c'est le champ "Premier" qui se retrouve en clef primaire. On a beau dire que c'est pas un bug, moi je la trouve très louche cette "feature".

par _activmik » 05 août 2008, 09:18

Il y a un surement un rapport avec MERISE :wink:

par Berzemus » 04 août 2008, 21:36

it's not a bug, it's a feature !!

Peut-être que c'est pour bien les mettre en évidence ? de toute façon, qu'importe l'ordre des colonnes..

par Louisss » 04 août 2008, 19:39

Ok, je repose le problème différemment.

D'abord, je ne parle pas de faire une base mais juste une table. Dans SQLite comme dans beaucoup d'autres SGBD, on n'est pas du tout obligé de créer une table directement avec sa clef primaire : on peut la définir après coup.
Deuxièmement, quand je parle de "premier champ", je veux dire par là que les champs d'une table sont toujours présentés dans un certain ordre : l'ordre dans lequel on les a définis lors de la création de la table.
Maintenant, ce que je constate, c'est que je ne peux pas demander à SQLiteManager de placer la clef primaire sur un autre champ que celui qui a été défini en premier. Et je ne vois vraiment pas pourquoi je devrais forcément choisir ce champ là comme clef primaire. D'ailleurs, dans ce cas, pourquoi l'interface de SQLiteManager semble-t-elle proposer que n'importe quel champ devienne clef primaire ?
Quand on crée une table, on peut bien cocher n'importe quel champ comme clef primaire, non ? Et on peut bien à tout moment modifier un champ et le cocher comme clef primaire, non ? Donc ma question est : pourquoi ça ne marche pas, pourquoi est-ce qu'il m'oblige à utiliser le 1er champ de ma table comme clef primaire ? Est-ce un bug connu de SQLiteManager ou un problème de configuration chez moi ?