Vous n'êtes pas identifié(e).
je vais opter pour la solution où le champ id_test sera en 1ère position dans la table.
C'est une idée aberrante. En effet, rien ne vous garantie que ce sera toujours le cas. Par nature dans le SGBDR il n'y a aucune notion d'ordre. Lisez ce que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlaz/erreurs/#L6
http://blog.developpez.com/sqlpro/p5867 … -des-ense/
A +
je souhaite effectivement que les tables soient verrouillées; c'est exactement ce que je cherche à faire
Le problème est qu'il faut que vous soyez conscient que la montée en charge en sera fortement altérée avec des problématique de survenance de verrous mortels....
A +
SQLpro, pourrais tu avoir un minimum de politesse vis à vis des gens présents sur le forum ?
Je n'ai jamais été politiquement correct. Je ne le souhaite d'ailleurs pas, et ce n'est pas à mon âge que l'on va me faire changer de comportement. En revanche je n'ai jamais eu de propos diffamatoire ! Et permettez moi de vous faire remarquer que vous commettez une erreur...
En effet, je n'ai pas dit que jhashe était stupide ... Relisez SVP mes propos. J'ai simplement dit que cette idée était stupide. Même les meilleurs arrivent parfois à dire des bêtises. Par exemple Arago, qui était le plus brillant savant de son époque, à dit des chemins de fer (discours du 14 juin 1836) que les gens allaient s'asphyxier dans les tunnels, que les trépidations de la machine allaient leur décoller le cerveau et qu'ils allaient être atteint de strabisme à force de regardez la paysage défiler à la vitesse sidérante de 40 km/h...
Pour ma part, j'ai constaté que les conversations de salon était rarement entendu et que des propos virils, même et justement parce qu'ils suscitent des émotions, ont plus de force à pénétrer dans le subconscient des gens, et cela de la même manière que l'on apprend plus de ses échecs que de ses réussites !
Regardez autour de vous... Le gens s'intéressent plus à Sissi impératrice ou à Rambo le guerrier ?
Hier j'ai déjeuner avec Richard Stallman, le pape du logiciel libre.. J'ai été très intéressé par le violence de ses propos et par la férocité de son action... Pour lui, le libre est un combat et il a admis que s'il avait été là dans les années 50 avec de tels propos, il aurait probablement été chassé par Mc Carthy !
Enfin n'oubliez pas que les propos tenu dans un forum, bien que leur forme soit écrite, n'en relève pas moins de la langue parlé, car il faut aller vite à l'essentiel. Nous ne somme donc pas dans la rédaction d'article qui nécessite des heures ou des journées de synthèse et de peaufinement. nous somme dans le direct, l'urgence et l'essentiel... C'est pour cela que cet endroit s'appelle forum de discussion, or un discours, c'est bien de la langue parlé ! Et, pour rappel, tout ceux qui se sont amusé à censurer des propos jugés politiquement incorrects alors qu'il n'était en rien diffamant ont vu leur forum péricliter. C'est tout le problème de l'exercice de la démocratie !
Bref, accepter d'être critiqué, même violemment, est une preuve de bonne santé de notre système démocratique. Et croyez moi, je suis souvent critiqué sur mes propres écrits !!!
A +
Probablement une limite lié à l'adressage 32 bits si votre client est en 32 bits (2 ou 4 Go de data).
A +
Il est absolument stupide de vouloir faire une transaction dans une IHM en mode asynchrone (Ajax) !!! Voulez-vous que les tables soient verrouillées pendant tout le temps que les utilisateurs mettrons à discuter devant l'IHM, au point de bloquer tous les autres utilisateurs ??? Autant revenir à la manipulation de fichiers en Cobol !!!
Là c'est vous qui avez une problème de méthode et de choix des outils de développement...
Au passage lisez la diatribe que j'ai écrit sur les errements de développeurs face aux outils de, soit disant "haut niveau".... http://img1.lemondeinformatique.fr/fich … aisses.pdf
A +
Pourquoi ne pas tout simplement démarrer une transaction ????
a +
En .net, ça passe... !
A +
En principe pour renvoyer les résultats d'une requête le moteur SQL doit travailler en mémoire exclusivement. Avez vous une RAM suffisante pour renvoyer au client les 9 millions de lignes ?
A +
C'est le genre de bouquin très pointu sur lequel la plupart des choses évoquées ne sont pas possible sous PG.
Si tu t'intéresse à la physique des SGBDR, alors il faut lire Stonebraker, c'est lui qui a mis au point la plupart des algo utilisés par les SGBDR et est à l'origine de PostGreSQL...
Voici mon livre de chevet quand j'explique à mes étudiant ce qu'il y a sous le capot : Readings in Database Systems, 4th Edition (MIT Press 2005)
http://www.amazon.com/Readings-Database … =8-1-fkmr1
A +
Sauf qu'en matière de performances, PG est loin d'égaler SQL Server sur de gros volumes : il n'est toujours pas capable de multithreader les opérations d'un même plan de requête... C'est d'ailleurs ce que reprochaient les gens de Bull lors des PG Days organisés par Dalibo.
En gros, lorsque je fais certaines opérations : tri, groupage, agrégat... SQL Server lance plusieurs thread là ou PG n'en fait jamais qu'un. Au final des résultats totalement incomparable sur le plan des performances.
Ajoutons à cela les vues indexées qui n'existent pas et là, y'a pas photo SQL Server bât à plate couture PG...
En sus de cela l'article est intéressant car il dit clairement que pour faire au minimum les mêmes performances avec PG que celles de SQL Server, il faut se farcir un paramétrage imbitable (voir page 11 du document) alors que sous SQL Server il n'y a rien à faire, bref une économie d'une journée de boulot de spécialiste PG (soit au moins 1000 € HT)....
Mais bon, PG reste un excellent choix pour des bases a petite ou moyenne volumétrie (une centaine de Go...).
A +
...Utiliser des vues, c'est quand même plutôt une méthode détournée, comme faire des liens sur un binaire dans un système de fichiers ne possédant pas d'ACL. Du moins à mon avis.
Sauf que vous oubliez que la conception des bases de données relationelle repose justement sur la notion de vues !
Les 4 étages de la modélisation sont :
1) le MCD (modèle ceonceptuel de données) : entité + association, avec la notation que vous voulez : Merise, UML, ER...
2) le MLD (modèle logique de données), c'est à dire les relations au sens mathématique
3) le MPD (modèle physique de données) c'est à dire les tables, index, contraintes...
4) le MED ou modèle externe de donné, grand oublié, c'est à dire les vues. En fait c'est à partir des vues que toute application devrait être écrite !
Sur l'importance des vues, je vous invite à relire les 12 règles de Codd, père fondateur des SGBDR... Vous serez étonné de voir que sur 12 règles, au moins 4 parlent des vues. http://sqlpro.developpez.com/SGBDR/ReglesCodd/
Dommage que PG soit en retard par rapport aux grand SGBDR comme Oracle, SQL Server, IBM Db2 ou Sybase sur ce sujet, notamment sur la misajourabilité des vues !
A +
Hé bien si c'était le cas c'est une aberration de PG ! En effet, sur une vue vous ne pouvez manipuler aucune des colonnes auquel la vue ne fait pas référence explicitement.
Voici un exemple et ce à quoi il devrait conduire :
CREATE TABLE T(C1 INT, C2 INT);
INSERT INTO T VALUES (1, 1);
INSERT INTO T VALUES (2, 2);
CREATE VIEW V
AS
SELECT C1 FROM T;
SELECT *
FROM V
WHERE C2 = 1.
Ceci devrait causer une erreur du genre : "Nom de colonne non valide : 'C2'."
C'est d'ailleurs bien le cas dans la version 8.4 !
ERREUR: la colonne « c2 » n'existe pas
LINE 3: WHERE C2 = 1
^
********** Erreur **********
ERREUR: la colonne « c2 » n'existe pas
État SQL :42703
Caractère : 26
A +
Si vous n'avez pas le privilège de SELECT sur la colonne C2 alors le WHERE C2 = 5 devrait conduire à une erreur ! En effet par ce biais vous pourriez donc connaître les valeurs des lignes pour lesquelles C2=5, alors qu'on en interdirait la lecture, ce qui est donc parfaitement absurde !!! Je n'ai pas fait l'essai, mi si c'est le cas dans PG, alors c'est un bug de sécurité très important !
A +
Il suffit d'utiliser une vue ! Une vue c'est une requête SELECT sur une table (ou plusieurs) et les vues peuvent être mise à jour (INSERT, UPDATE, DELETE).
C'est du SQL de base.
Pour apprendre le SQL, mon site web, comme mon bouquin, peuvent vous être utile.
A +
C'est une des limitation de PostGreSQL. En effet sous Oracle, SQL Server ou DB2, les tables ou colonnes non utilisée dans la requête finale résultant d'une requête sur des vues sont systématiquement ignorées. Mais PostGreSQL commence à y venir. Dans la dernière version, l'optimiseur sait supprimer les jointures inutiles....
A +
Hi guys,
J'ai une question concernant l'optimisation d'une DB déjà en prod (pgsql 8.4)
Je cherche à obtenir de façon un peu "industrielle" les index manquants.Je connais un peu pg_fouine, et je joue actuellement avec pg_stat_statements.
Ca me permet de détecter un peu les requêtes problématiques, mais c'est plutôt fastidieux et pas assez industriel à mon goût.L'optimiseur pgsql est-il capable de dire à chaque fois qu'il a cherché un index sur une table ? Quand il décide de faire un scan parce que l'index qui conviendrait n'existe pas ... est-ce qu'il stocke cette info qqpart ? Ca serait bien utile.
Merci pour vos réponses.
Mathieu
Non, actuellement PG ne propose pas de vue du genre "missing index", comme c'est le cas de MS SQL Server.
Pour faire cela, vous pouvez utiliser pgfouine pour trouver les requêtes les plus lentes, mais il faut mutualiser les paramètres, puis par la 1ere requête donnée par gleu trouver les scans relatifs aux tables exprimées dans les requêtes lentes et enfin analyser les plans de requête un a un et prévoir les index manquants.
A +
id_source = (select id...
n'est sémantiquement pas la même chose que
id_source IN (select id...
En effet derrière un opérateur =, SQL s'attend à une seule valeur. Je m'étonne d'ailleurs que PostGreSQL laisse passer cette exécution et ne renvoi pas un message du genre "la sous requête a retourné plusieurs valeurs. Ceci est interdit lorsque l'opérateur attend une valeur scalaire" ! Peu importe que vous ayez fait un LIMIT 1 qui n'est qu'une clause cosmétique non relationnelle !
A +
Merci encore
juste pour dire, en suivant les conseils et en mettant tout dans une seule et grosse requete le tps d'exécution tombe, que dis-je : CHUTE à 14 secondes....... ;-)
Normal; un traitement ensembliste (requêtes SQL) est optimisable. C'est d'ailleurs le rôle de l'optimiseur ! Et tout bon SGBDR comme PostGreSQL en est doté !!!
Un traitement itératif ne l'est pas car le code est statique !
De plus en ajoutant les bons index, vous arriverez certainement à diminuer encore les temps de réponse !
A +
E
2°) Chaque database a 2 catalogues ANSI (information_schéma) et PostgresSql (pg_catalogue)... quelle est la différence entre les deux ?
3°) La notion de schéma n'est pas identique à oracle => Ok ... Par quoi/qui est défini un schéma dans postgrès (dans mes databases le seul schéma qui existe est le schéma 'public')...
La norme SQL définit la notion de schema SQL qui est un espace logique de placement des objets dans les bases.
Les schémas SQL (la notion de "catalog" est en fait la dénomination normative de la notion de "base de données") sont obligatoire et vous ne pouvez pas créer d'objet sans passer par un schéma.
Il y a donc un schéma SQL par défaut par base et par utilisateur :
- Dans postgreSQL le schéma par défaut de la base s'apelle PUBLIC. (Dans SQL Server il s'appelle dbo).
- pour l'utilisateur c'est aussi PUBLIC à moins que vous n'ayez spécifié un autre schéma à la création de l'utilisateur.
INFORMATION_SCHEMA est un schéma SQL par défaut contenant les vues d'information de schéma de la norme SQL. Voir : http://sqlpro.developpez.com/cours/sqla … partie2#L9
pg_catalogue est un schéma spécifique à PostGreSQL qui contient des objets de méta description et les fonctions système (par exemple ABS).
Vous pouvez créer autant de schéma SQL que vous souhaitez afin de structurer vos objets. C'est en général une bonne façon de faire que de mettre les objets de la paye dans un schéma paye, ceux de la compta dans un schéma compta, de la prod....
Il vaut mieux toujours préfixer les objets par leurs schémas. Ceci possède deux avantages :
1) la résolution de nom est instantanée (il n'y a pas à interroger les tables système pour savoir quel est le schéma par défaut de l'utilisateur)
2) le cache conserve mieux les plans de requête : les objets sont connus et strict
A +
