Vous n'êtes pas identifié(e).
Quel est donc l'intérêt de faire un trigger complexe couteux et que visiblement vous ne maitrisez pas....
je voudrais mettre à jour l'état du stock (c'est à dire la valeur de la colonne etat_article)
pour un UPDATE OR INSERT je dois vérifier si quantite_stock > quantite_stock_min si c'est le cas je mettre à jour la colonne :
etat_article = 'EN STOCK'sinon (quantite_stock < quantite_stock_min), je mettre etat_article = 'A COMMANDER'
...alors que la solution est d'utiliser une vue ?
RAPPEL : toutes les applications que l'on développe avec accès à une base de données relationnelle, devraient faire appel exclusivement à des vues (et éventuellement des procédures stockées). Cela s’appelle le MED ou Modèle Externe de Données.
Dans votre cas :
1) La bonne table
CREATE TABLE articles
(
id_article bigserial NOT NULL,
id_sous_famille bigint NOT NULL,
code character varying(300) NOT NULL,
article character varying(300) NOT NULL,
designation character varying(300) NOT NULL,
id_fournisseur bigint NOT NULL,
quantite_stock integer NOT NULL,
quantite_stock_min integer NOT NULL,
type_derniere_mouvement character varying(40) NOT NULL,
utilisateur character varying(50),
datecreation timestamp with time zone,
datemaj timestamp with time zone,
CONSTRAINT pk_article PRIMARY KEY (id_article),
CONSTRAINT articles_fournisseurs_fk1
FOREIGN KEY (id_fournisseur)
REFERENCES fournisseurs (id_fournisseur)
MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT,
CONSTRAINT articles_sousfamilles_fk1
FOREIGN KEY (id_sous_famille)
REFERENCES sousfamilles (id_sous_famille)
MATCH SIMPLE ON UPDATE NO ACTION ON DELETE RESTRICT,
CONSTRAINT un_article_designation UNIQUE (designation)
)2) La vue
CREATE VIEW V_articles
AS
SELECT *,
CASE
WHEN quantite_stock >= quantite_stock_min THEN 'EN STOCK'
WHEN quantite_stock < quantite_stock_min 'A COMMANDER'
ELSE NULL
END AS etat_article
FROM articlesN'oubliez par qu'une vue peut être mise à jour, sauf pour les colonnes dérivées (constantes, calcules...)
A +
- en terme "SQL", il y a-t-il plus simple ?
Oui, il suffirait de faire un MERGE qui permet de combiner INSERT et/ou UPDATE, DELETE...
Malheureusement cela n'est pas encore implémenté sous PostGreSQL (encore une fonctionnalité de la norme en avance sur les réalisations.... ;-))
De toutes façon, si votre table est organisé en cluster il y a des chances que toutes les lignes manipulées figurent dans la même page de données. De ce fait il n'y aura donc qu'une seule écriture physique !
A +
Je ne vais pas rentrer dans cette conversation (entre SQLpro et Marc) car elle ne m'intéresse pas. Je viens juste corriger une erreur. Avec PostgreSQL, il est possible de différer les clés étrangères, les contraintes uniques et les clés primaires.
Mea culpa, j'en étais pas encore à la version 9 ! (je ne l'ai installé que depuis quelques jours !).
A +
En tout cas, le respect de la norme en lui même n'est pas vraiment quelque chose qu'on constate dans l'historique de développement des bases de données relationnelles. Entre autres quand la norme est en retard (l'exemple le plus flagrant est évidemment les jointures externes, qui ont eu autant de syntaxes que de moteurs l'implémentant, avant que ça ne soit enfin normalisé), ce qui a à peu près toujours été le cas à ma connaissance pour la normalisation.
Ta connaissance est donc mauvais, car il y a beaucoup de choses dans la norme qui ont mis des lustres à être implémenté. Quelques exemples :
1) le DATALINK (rnorme SQL 1999) apparait pour la première fois dans IBM DB2 en 2002, dans SQL Server en 2008
2) les contraintes defférables date de la norme de 1992... Elles ont été implémentée qu'a partir de la version 8 d'Oracle et très récemment dans PG (mais uniquement pour les FK)
3) les assertions, n'ont jamais été implémentées à ce jour, sauf dans certains SGBDR confidentiel (Ocelot de Peter Gulutzan).
...
Et heureusement que le respect de la norme n'a pas empêché l'apparition initiale de ces syntaxes, les gens avaient des problèmes à résoudre à l'époque, que la norme ne permettait pas.
Sauf que la plupart du temps les solutions était incomplètes ou ineptes. Exemple la récursivité avec CONNECT BY Prior dans Oracle qui ne permet pas le parcours de graphe, les jointures externe *= de Sybase qui sont mathématiquement fausses.
Mais je suis très content d'avoir quelques types de données non normalisés dans PostgreSQL, et qui me rendent bien service (cidr par exemple, pas tant pour le gain de place que pour les opérateurs). Et tant pis si je suis un
tyran parce que ce n'est pas dans la norme.
Intéressant, certes, mais parfaitement idiot... En effet puisqu'il y a le CREATE DOMAIN, alors autant s'en servir. Par exemple dans SQL Server il y a un domaine sysname qui est un NVARCHAR(128) pour représenter, conformément à la norme les noms des objets SQL.
Il aurait donc fallu simplement prévoir ces types en tant que domaine pré établis dans la base !
Encore une fois, la norme est beaucoup plus intelligente que la plupart des gens le suppose... C'est normal qu'elle soit très intelligente car ce sont l'ensemble des éditeurs des différents SGBDR qui y participent. Et non pas quelques savants dans leur tout d'ivoire. Et pour valider une syntaxe il faut en étudier tous les aspects ce qui est rarement fait par un seul éditeur, trop cotent de tirer la couverture à lui pour faire en sorte de ferrer le développeur !
A +
Dites, SQLPro, pourquoi ne pas mettre «Bref, apprenez SQL... Mon livre comme mon site web peuvent vous y aider ! http://sqlpro.developpez.com/» directement dans votre signature, puisque vous la mettez dans presque chacun de vos posts ? Vous gagneriez du temps ?
Parce que cela n'est pas systématique... :-) Tout n'est pas dit dans SQL. Par exemple les index ça n'existe pas en SQL !
Par ailleurs, comme expliqué dans mon post au dessus, la principale raison de l'absence d'entiers non signés dans PostgreSQL n'est pas le respect «bête et méchant» de SQL, c'est avant tout un problème de gestion des casts. Difficile de savoir, quand quelqu'un saisit un entier, s'il en veut un signé, ou un non-signé. Donc c'est tout le temps signé et on n'en parle plus, ça évite les problèmes d'interprétation. PostgreSQL n'a jamais été opposé à l'ajout de types qui ne sont pas dans le standard SQL (encore heureux…).
Non, vous faites fausse route. Rien n'empêche de tenter un cast de 'ABC' en INT et donc de recevoir une erreur...
Le respect des normes est plus important que l'ajout bête et méchant de fonctionnalités inopinées (ce genre de merde que l'on trouve systématiquement dans MySQL par exemple), car SQL le permet via d'autres moyens comme CREATE DOMAIN (depuis la norme SQL 2 de 1992) et comme le CREATE TYPE (de la norme SQL:1999).
De plus, sur la norme que PostGreSQL respecte assez bien (et depuis son origine que j'ai suivi dès la version 2 de 1990 avec les travaux de Michael Stonebraker), je suis toujours stupéfait de voir des commentaires "anti" norme, surtout de la part de ceux qui prônent le libre. N'oubliez pas que la première des libertés c'est avant tout de ne dépendre de rien... Or pour ne pas dépendre il faut que les choses soient interchangeable. C'est pourquoi les normes et les standards (ceux d'Internet à travers notamment les RFC) sont très importantes... Souvenez vous du klingonien (http://www.dicosmo.org/Piege/cybersnare/piege.html) !
Autrefois, il n'y avait pas de norme. Avant la révolution industrielle au 18e siècle, chaque seigneur imposait sur son territoire ses propres mesures de poids de volume que le commerçant devait acheter fort cher auprès du seigneur. C'était une forme d'impôt.
Les entreprises ont été obligée de se conformer à des standards et des normes, car cette situation à conduit à de nombreux accident mortels lors de l'avènement du chemin de fer :
- chaque région ayant ses pas de filetages, ses écrous et ses boulons, il a fallut dépenser trois fois plus pour adapter les éléments de structure au fur et à mesure de l'avancé des rails, ceci était contre productif....
- chaque village ayant son heure propre, les premiers trains se télescopaient et il en résultait des accidents mortels.
Aujourd'hui hélas on trouve de nombreuses personnes qui avance le soit disant carcan de la norme pour faire n’importe quoi. Je ne peut pas m'empêcher de penser que ces gens là feront d'excellent tyrans !
A +
Contrairement à MySQL, PostgreSQL est un SGBD relationnel fortement normatif. Il respecte donc les types SQL et parmi ces types de données il n'existe aucun entier non signé, car cela fait partie de la sémantique des données que l'on obtient par des contraintes, notamment de domaine.
Or MySQL implémente très mal les contraintes, certaines toujours pas, et les quelques unes que MySQL implémente, ce n'est que depuis peu.
Pour palier ces défauts, MySQL à rajouter des types de données spécifiques et farfelus comme les entiers non signés, qui n'ont pas leur place dans un SGBDR.
Pour faire ce que vous demandez il suffit de créer un DOMAIN SQL.
Exemple :
CREATE DOMAIN UNSIGNED_INT
AS INT
CONSTRAINT CK_POSITIVE
CHECK (VALUE >= 0 );Dès lors vous pouvez utiliser UNSIGNED_INT comme n'importe quel type SQL. Exemple :
CREATE TABLE T (I UNSIGNED_INT);test avec insertion d'une bonne valeur :
INSERT INTO T VALUES (25)test avec insertion d'une mauvaise valeur :
INSERT INTO T VALUES (-7)ERREUR: la valeur pour le domaine unsigned_int viole la contrainte de vérification « ck_positive »
Tout cela fait partit intégrante du langage SQL de base...
Bref, apprenez SQL... Mon lire comme mon site web peuvent vous y aider ! http://sqlpro.developpez.com/
A +
Bref, comme vous l'avez constaté, c'était bien l'erreur que j'ai pointé... Mais il n'est pas si simple de traiter tous les cas... Comme je poste à peu près 50 fois par jour sur différents forums :
En france :
http://www.developpez.net/forums/f4/bases-donnees/ (dont ceux sur PG),
http://social.msdn.microsoft.com/Forums … fr/threads
http://social.msdn.microsoft.com/Forums … fr/threads
forum.phpfrance.com/sql-bases-donnees/
mais aussi à l'étranger...
Il ne m'est pas possible d'être toujours très explicite, d'où le renvoi vers d'autres articles, lieux, ouvrages...
En sus de cela il me faut travailler !
A +
Un NOT IN avec une sous requête retournant des NULL ne donne jamais rien....
C'est un grand classique du langage SQL !
Démonstration :
SELECT 1 AS C
WHERE 2 NOT IN (3, NULL);Résultat vide... Alors que :
SELECT 1 AS C
WHERE 3 IN (3, NULL)Donne 1.
Bref, apprenez SQL, mon livre comme mon site Web peuvent vous y aider !
A +
Dans la table ? Non.
Bien sur que si... Cela fait partie de la norme SQL que PG respecte assez bien !!!
Démo :
CREATE TABLE TRE (C1 NUMERIC(16,2));
INSERT INTO TRE VALUES (1), (1.23), (1234567.89), (1.23456789);
SELECT * FROM TRE;Et la réponse :
1.00
1.23
1234567.89
1.23
A +
Tu as raison, j'ai oublié le :
SELECT * FROM INFORMATION_SCHEMA.ROUTINE_PRIVILEGES
A +
Tout se trouve dans les vues normalisées d'information de schémas :
SELECT * FROM INFORMATION_SCHEMA.TABLE_PRIVILEGES
SELECT * FROM INFORMATION_SCHEMA.COLUMN_PRIVILEGES
Pour un tutorial sur les privilèges en SQL (et non les "droits", cela n'existe pas en matière SQL), mon site web, comme mon bouquin peuvent vous y aider... En particulier :
http://sqlpro.developpez.com/cours/sqlaz/dcl/
PG y a rajouté quelques éléments : privilèges "RULE" et possibilité de placer des privilèges sur une database, un tablespace, un schema SQL, un language PG et sur une sequence PG.
A +
Bonjour,
Voici un petit article que je viens de publier concernant la possibilité de créer des contraintes CHECK permettant de valider des données de la tables avec une table externe.
http://blog.developpez.com/sqlpro/p9902 … terne-ave/
A +
L'attribut nom dépend bien uniquement de la personne.
Non, c'est là ou vous vous trompez. L'attribut nom est attribué à toutes une même famille par filiation, même s'il arrive qu'il y ait des changements de nom, ils se produisent rarement (il faut une décision du conseil d'état). Une personne même marié ne change pas de nom, elle ajoute le nom de son mari, ou la concaténation des noms.
Donc il y a bien une entité unique FAMILLE avec juste le nom.
C'est un exercice que je donne régulièrement dans mes cours de modélisation.
Et justement en cas d'erreur orthographique, on aura pas besoin de rectifier plys d'une seule information atomique (FN de Boywxe Codd).
A +
«le nom est toujours unique pour une même famille». Même en France, je doute que ça soit vrai… d'où ma question sur la filiation biologique, d'ailleurs.
Rien n'empêche cela car vous êtes libre de faire l'association que vous souhaitez entre la personne et son nom de famille !
Je n'ai pas encore bien regardé le diagramme proposé, mais mon but c'est qu'il soit possible d'avoir un nom de famille différent. Comme par exemple avoir des parents qui ne soient pas mariés et l'enfant a seulement le nom du père. D'après le petit texte joint avec ce diagramme, ce n'est pas possible.
Idem !
Le problème serait plus simple si le modèle était correct. Et il est incorrect car il ne respecte pas les formes normales.. Il vous suffit d'ajouter une entité famille contenant les noms et d'associer la personne au bon nom de famille.
En effet dans votre modèle que se passe t-il si l'orthographe d'un nom de famille est erroné pour une personne ? Vous avez plusieurs tuples à mettre à jour (avec tous les risques que cela comporte, notamment d'en mettre à jour certains et pas d'autres, donc de générer une deuxième erreur), ce qui viole une règle fondamentale de la modélisation. Alors que dans le modèle proposé, vous n'avez plus ce contrôle à faire car le nom est toujours unique pour une même famille. Et si vous voulez le corriger il n'y a qu'une seule valeur atomique à modifier....
A +
Il se trouve que certaines mauvaises pratiques de Windows ont été remaniées dans la version 2008. Par exemple, lors des formatages de disques, Win 2000 à 2003 prenait une entête de disque de 63 Ko avec un formatage de bas niveau à 64 Ko. Ce qui faisait décaler toutes les lectures de 1 Ko et donc obligeait le serveur à lire physiquement deux fois plus de données que nécessaire dans les version antérieures à la 2008... De même il y a eu de notable améliorations dans la gestion de la mémoire. Enfin, et contrairement à ce que prétendent certains discours très obsolète, Windows présente aujourd'hui (et à depuis la version 2003) un niveau de fiabilité qui a été jugé supérieur à ceux des linux dans des études menées dans de grands comptes....
Par exemple le fameux coup du "faut rebooter ton serveur Windows toutes les nuits si tu veut pas avoir d'ennuis" est quand même plus qu'obsolète. Je veux bien que cela ait été vrai du temps de Windows 16 bits (3.11) mais depuis Windows 2000 SP 4 je n'ai jamais entendu parlé de fuites de mémoire par exemple ! (sauf composants hors MS bien entendu...).
Pour ce qui est des performances de PostgreSQL sous Windows, il y a un coût, qui dépend des types de requêtes et d'usage, mais est souvent mesuré à 20 à 30%, par rapport aux performances de la même machine sous Linux. Tout simplement parce que PostgreSQL est écrit pour des systèmes Unix, utilise des appels système Unix en permanence (fork, mémoire partagée système 5, sémaphores, etc…) et que sous Windows, il y a une (fine, sauf pour fork) couche d'émulation. D'où la question de Damien. Mais il est tout à fait possible que ça soit un test sur lequel ça aurait eu peu d'impact.
Ce serait intéressant de creuser ce point sur un même serveur. En gros, jouer une dizaine de requêtes sur une volumétrie non négligeable (du gendre base 20 Go RAM 4 Go) et voir les différences entre Windows et Linux. mais je ferais le pari qu'avec Windows 2008 R2, PostGreSQL arrive en tête par rpport à Linux sur les requêtes à forte volumétrie !!! Je suis prêt à parier une caisse de champagne !
A +
Étant donné le test, difficile de dire ce qui fait la différence. Je présume (j'ai regardé très vite l'exemple) que c'est avant tout l'acquisition de verrous sur les enregistrements de cette table de compteur qui dure longtemps sur le test ?
S'agissant de lectures, cela influe peu...
Non je dirais ce qui fait la différence avec MS SQL Server c'est l'utilisation de l'opérateur CROSS APPLY. Microsoft à proposé sa normalisation au comité. SQL...
A +
Pourquoi le choix de PostgreSQL 8.4 ? La version 9.0 aurait probablement donné de meilleures performances...
Bonne remarque. Mais j'attends en général toujours 1 an avant de prendre la version suivante par soucis de sécurité. Cependant, dès que j'ai le temps je vais refaire des tests avec la version 9.
Par ailleurs vous n'indiquez pas le profile matériel et OS de la plateforme de test. J'imagine que vous avez utilisé Windows ?
Si toutes les plateformes sont mentionnées (voir paragraphe CONDITION DES TESTS). Les tests comparatif ont été effectué sur Windows, évidemment, car SQL Server n'est pas disponible sous Linux.
Ceci dit, cela ne change rien à mon sens. Je dirais même qu'il y aurait un léger désavantage, car les formats de page de données étant plus petits un extra overhead va s'ajouter sur les parcours.
De plus il faudrait formater la même machine sous Linux et Windows pour que le test soit équitable... Si quelqu'un veut le faire, je prête mon HP Proliant DL 385 G2 pour ce faire !!!!
A +
Bonjour,
Pour information, ce petit benchmark concernant un besoin d'extraction de données.
La question est simple... Partant d'une table de période de temps, agréger les périodes recouvrantes par item, pour n'en avoir plus que l'essentiel... (packing d'intervalles).
Tests effectuées sur MySQL version 5.5, PostGreSQL version 8.4 et MS SQL Server version 2008 R2 avec des jeux d'essais allant de 1 000 à 3 000 000 de lignes.
Résultats :
* PotsGreSQL est entre 3 et 13 fois moins rapide que SQL Server
* MySQL est entre 59 et 5 947 fois moins rapide que SQL Server
...en fonction de la montée en charge.
Bref, une excellente surprise pour PostGreSQL qui confirme grandes fonctionnalités, qualités et performances dans le monde des SGBDR libre !
Tous les détails, les conditions et les scripts SQL pour rejouer ce benchmark chez vous sur : http://blog.developpez.com/sqlpro/p9826 … -avec-sql/
A +
Le SELECT * est une chose à ne jamais utiliser en production. Il a été créé pour la mise au point des requêtes SQL lors des essais, mais il est doublement dangereux.
Quelques exemples :
- en cas de modification de la structure de la table, certaines requête vont faire planter les applications
- en cas d'ajout d'une colonne de type LOB, les performances vont devenir catastrophiques
A +
Mea culpa et merci ! J'ai cherché une syntaxe bien plus compliquée !
A +
Bonjour,
Il semble que la fonction RANDOM ne veuille jamais rien savoir lorsqu'elle est incorporée dans une fonction PG au sein d'un INTERVAL...
Exemple :
CREATE OR REPLACE FUNCTION F_TEST (n1 INT, n2 INT)
RETURNS TIMESTAMP STABLE AS $$
DECLARE n3 INT;
BEGIN
n3 = n1 + n2 + FLOOR(10 * RANDOM());
RETURN CAST('2011-01-01' AS TIMESTAMP) + INTERVAL '$3 DAYS';
END; $$ LANGUAGE plpgsql ;à la place de STABLE, vous pouvez mettre ce que vous voulez : VOLATILE, IMMUTABLE....
Bref, l'exécution de cette fonction :
SELECT F_TEST (1, 2)Ne donne jamais que toujours la même chose :
2011-01-04 00:00:00
Moi je chercher à faire quelque chose d'aléatoire !!!!
A +
Et oui, toujours l'utilisation de framework et d'ORM de plus en plus catastrophique pour les performances, alors que le développement natif est bien plus simple dans le SBDR directement via des proc stock des vues etc... Chose que je dénonce depuis des années : http://img1.lemondeinformatique.fr/fich … aisses.pdf
A +
Sauf que les transactions préparées génère du COMMIT à deux phases, et rien ne garantit la bonne finalité des transactions. Pire, même, on peut se retrouver avec une transaction partiellement validée (et donc une autre partie annulée) sans savoir ce qui a été validé et ce qui a été annulé !
A +