Forums PostgreSQL.fr

Commençons par la sémantique... Il faut vous débarrasser du mot DROIT qui n'a pas sa place dans les SGBDR relationnel. La notion de "droit" est purement système.. Droit de lire, d'écrire... Or dans un SGBDR le seul qui a le droit de lire ou d'écrire est le moteur relationnel ! Tout ce que les utilisateurs peuvent faire c'est envoyer des requête SQL (qui sont des demandes) en espérant qu'elles produisent leur effet sur les objets manipulés.

Donc un PRIVILÈGE est la permission d'utiliser une COMMANDE SQL particulière sur un OBJET précis (vue, table, routines...).

Dans une base de données on est confronté à un problème d’œuf et de poule... Pour créer une base il faut un utilisateur SQL qui sera le propriétaire des objets et aura le droit de vie ou de mort et sur ces objets et possède tous les privilèges dessus implicitement. Cet utilisateur ne pourra en aucun cas être supprimé, sinon vous ne pourriez plus, ni modifier, ni supprimer les objets existants, ni même (et bien entendu) transmettre les privilèges sur ces objets.

Ensuite, sachez que la délivrance des privilèges est chainée. Ainsi le propriétaire peut donner tous les privilèges qu'il souhaite, et s'ils les donnent avec la possibilité de rétrocession (WITH GRANT OPTION), alors celui qui a acquis les privilèges peut à son tour les transmettre. Ainsi USER_A donne par GRANT des privilèges à USER_B et si WITH GRANT OPTION, alors USER_B peut faire un GRANT à USER_C des privilèges acquis...

De plus les privilèges sont cumulatifs. C'est à dire qu'un privilège donné 3 fois par 3 utilisateurs nécessite 3 REVOKE pour que l'utilisateur final n'ait plus la possibilité d'agir.

Exemple, soit USER_A, USER_B et USER_C. Si USER_A et USER_B possèdent tous les privilèges sur tous les objets et que les commandes suivantes sont passées :

USER_A lance la commande : GRANT SELECT ON Table1 TO USER_C;

USER_B lance la commande : GRANT SELECT ON Table1 TO USER_C;

alors si USER_A récuse la commande transmise par :

USER_A lance la commande : REVOKE SELECT ON Table1 TO USER_C;

alors USER_C peut toujours faire un SELECT sur la Table1, parce qu'il a acquis de USER_B !

Pour savoir ou vous en êtes des privilèges, il faut lire les métadonnées avec les vues : INFORMATION_SCHEMA.TABLES_PRIVILEGES et INFORMATION_SCHEMA.COLUMN_PRIVILEGES.

Pour que vos utilisateurs puissent faire tout ce que vous voulez, il faut explicitement donner les privilèges adéquats sur chaque objet à chacun des utrilisateurs (si n objet et m utilisateurs, il faudra n x m GRANT !).
IMPORTANT : le GRANT ALL est supprimé dans la norme SQL ce qui signifie qu'un jour il risque de disparaître des commandes PG...
Pas de panique... le plus simple est de passer par un rôle.

1) création d'un rôle :

CREATE ROLE ROL_FAITOUT;

2) attribuer des privilèges à ce rôle :

GRANT INSERT, UPDATE, DELETE, SELECT ON TABLE_1 TO ROL_FAITOUT;

...

3) donner à vos utilisateurs, le rôle ROL_FAITOUT :

GRANT ROL_FAITOUT TO USR_1;

Vos utilisateurs peuvent maintenant faire toute ce que le rôle ROL_FAITOUT leur permet de faire.

Il est important au final de dissocier les rôles permettant des ALTER / CREATE / DROP (propriétaires des objets) et les rôles de production qui permet d'utiliser les objets de la base.

À NOTER : tout ceci fait partie de la norme SQL et est expliqué dans mon livre : "SQL, 4e édition, Colection Synthex, Pearson Educ.
Mon site web en donne un extrait : La gestion des privilèges La notion de rôle ayant été rajoutée avec la version 1999 de la norme SQL.

A +

Voici les droits associés à ce compte de service :

output
-------------------------------------------------------------------------------------------------
autorite nt\service réseau

Nom de privilège              Description                                               État     
============================= ========================================================= =========
SeAssignPrimaryTokenPrivilege Remplacer un jeton de niveau processus                    Désactivé
SeIncreaseQuotaPrivilege      Ajuster les quotas de mémoire pour un processus           Désactivé
SeShutdownPrivilege           Arrêter le système                                        Désactivé
SeAuditPrivilege              Générer des audits de sécurité                            Désactivé
SeChangeNotifyPrivilege       Contourner la vérification de parcours                    Activé   
SeUndockPrivilege             Retirer l'ordinateur de la station d'accueil              Désactivé
SeImpersonatePrivilege        Emprunter l'identité d'un client après l'authentification Activé   
SeCreateGlobalPrivilege       Créer des objets globaux                                  Activé   
SeIncreaseWorkingSetPrivilege Augmenter une plage de travail de processus               Désactivé
SeTimeZonePrivilege           Changer le fuseau horaire                                 Désactivé

Ceci dit, il n'est pas recommandé d'utiliser ce compte de service pour des raison de sécurité, mais d'en créer un spécifique au service PG avec les permissions qui vont bien, et si possible sous le contrôle de l'AD...

A +

Votre déclencheur ayant déjà sans doute été joué dans la précédente version de votre base (la base source), il est inutile et dangereux de le redéclencher. Dans ce cas de figure il est nécessaire de désactiver tous les déclencheurs.

A +

ATTENTION : au sujet des calendrier pour la gestion des données historique il est nécessaire de maintenir une base de calendrier et non pas un seul calendrier. En effet si le cas du calendrier républicain est simple (un date ISO = une date républicaine) il n'en est pas de même dans le temps et dans l'espace... En effet, en 1582 a eu lieu la réforme du calendrier julien vers le calendrier grégorien et les dates ont divergées dans les différentes pays...
Extrait de mon ouvrage "SQL", 4e édition, collection Synthex, Pearson Education 2012 :

"
Réforme du calendrier julien :

Au cours de l’Histoire et compte tenu de la précision accrue des calculs astronomiques, on constate que le calendrier julien souffre d’un manque de précision : la durée de l’année julienne est trop longue d’un peu plus de 11 minutes (365,25 jours au lieu de 365,2422) et, au fil du temps, le calendrier finit par retarder de plusieurs jours. C’est le pape Grégoire XIII qui entreprend de réformer le calendrier. Pour cela, 10 jours furent supprimés de l’année 1582, où le 4 octobre fut immédiatement suivi par le 15 octobre. Pour éviter de nouvelles dérives, la surévaluation de l’année julienne fut corrigée par la suppression de 3 jours tous les 400 ans. On ignore donc la règle des années bissextiles les années séculaires, sauf pour celles qui sont divisibles par 400.

On a donc 97 années bissextiles par période de 400 ans et la durée moyenne d’une année grégorienne est 365 + 97/100, c’est-à-dire 365,2425 jours.

Cette réforme nécessaire n’a pas été adoptée à la même date dans tous les pays, par exemple :
•        L’Italie, l’Espagne, le Portugal et la Pologne sont passés du 4 octobre 1582 au 15 octobre 1582.
•        La France (sauf l’Alsace et la Lorraine) est passée du 9 décembre 1582 au 20 décembre 1582.
•        Le Luxembourg est passé du 14 décembre 1582 au 25 décembre 1582.
•        La Belgique (alors province des Pays-Bas) est passée du 21 décembre 1582 au 1er janvier 1583.
•        Le Valais Suisse est passé du 28 février 1655 au 11 mars 1655.
•        L’Alsace est passée du 4 février 1682 au 16 février 1682.
•        Zurich, Berne, Bâle et Genève sont passés du 31 décembre 1700 au 12 janvier 1701.
•        L’Angleterre est passée du 2 septembre 1752 au 14 septembre 1752.
•        La Lorraine est passée du 16 février 1760 au 28 février 1760.
•        L’URSS est passée du 31 janvier 1917 au 14 février 1917.

"

FIN DE CITATION

ATTENTION (bis) : certaines régions sont passées alternativement d'u pays à l'autre du fait des guerres. Il n'est donc pas rare dans certains village d'avoir des date rétrograde en continuité de l'état civil (les trous sont moins visibles...)

A +

Difficile de vous repondre car cela dépend de la méthode de calcul...

C'est bien cela le hic. Le seul moyen de prouver la chose est de faire un test sur une base maquette avec une table préremplie dont vous connaissez très exactement le nombre de pages et de lignes concernées.

Cela dépend beaucoup de la nature de vos disque (SAS, SATA... - 7 500, 10 000, 15 000 rpm... SSD) votre organisation de disques (RAID 1, 5, 10...).

Ce n'est pas aussi simple que sous SQL Server ou vous avez SET STATISTICS IO ON qui permet de tracer toutes les IO de toutes les tables. mais vous pouvez utiliser une combinaison de
EXPLAIN (ANALYZE ON, BUFFERS ON) MaRequête... avec les vue systèmes pg_statio_* (http://www.postgresql.org/docs/current/ … stats.html)

Non, il estime le nombre de lignes en fonction des statistiques, mais à partir du moment ou vous avez les bons index - les statistiques n'étant disponible que sous les indes. Sinon, il n'y a pas comme sous SQL Server de statistiques de colonnes de tables.
Cependant vous pouvez tenter d'augmenter le nombre d'intervalle dans l'histogramme statistiques qui par défaut est un peu faible dans PG (default_statistics_target  / ALTER TABLE SET STATISTICS).

A +

De plus la norme SQL c'est 128 caractères maximum pour la taille des noms des objets et sachez que Oracle dans sa future version a entrepris enfin de se conformer à la norme en acceptant des noms longs pour tous ses objets c'est à dire jusqu'à 128 caractères...

A +

Le bon coin est indisponible la nuit justement pour assurer ces traitements là (reindexation, vacuum, DDL...)
Seule la lecture est possible, mais pas l'joute de nouvelles annonces. C'est son point faible.

Effectivement Oracle ou SQL Server permettent de faire du DDL et de la réindexation non bloquante sur des bases en prod 24/24 7/7.

A +

Effectivement c'est un des points faible de PG... Les mots de passe des connexions ne sont pas cryptés... Les algorithmes de hachage n'ayant rien à voir avec du cryptage !
Dans un audit pour une base de données de santé accessible en ligne nous avons soulevé ce point qui est incompatible avec les directives nationales sur le cryptage des données de santé.
Pire, pgcrypto ne permet pas de gérer les clefs de cryptage de manière externe (par boitier HSM par exemple) ce qui induit fatalement de les conserver en local, et comme les comptes de connexion sont des passoires...

A +

Vos méthodes beginTransaction(), SaveToDB() et commit() / rollback() partagent-elle la même connexion et celle-ci reste t-elle ouverte entre les différentes commandes ?

A +

PostGreSQL n'utilise pas plus d'un CPU/Coeur par requête. Dès lors les requêtes s'exécutent en parallèle pour des connexions différentes. Donc, rien à faire !!!
A +

Effectivement problème e conception gravissime ce qui se traduit par :
1) difficulté d'écrire des requêtes. D'où votre post...
2) performances dégradées...

Revoyez votre modèle pour un vrai MCD conforme à la normalisation et vous verrez que vous n'aurez plus de question à vous poser sur l'écriture des requêtes !

A +

Dans l'article cité, voici le requête :

SELECT DISTINCT T.oid AS table_space_oid,
spcname AS table_space_name,
CASE spcname
WHEN 'pg_default'
THEN setting || '/base/' || CAST(D.oid
AS VARCHAR(16))
WHEN 'pg_global'
THEN setting || '/global/'
ELSE spclocation
END AS location
FROM pg_tablespace AS T
CROSS JOIN pg_settings AS S
CROSS JOIN pg_database AS D
WHERE S.name = 'data_directory'
AND spcname <> 'pg_global'
AND D.datname = current_database();

A +