PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 Re : Installation » [Résolu]Installation sous Mac OS X Maverick » 27/05/2014 01:36:25

Ça marche merci gleu.
Je vais commencer par installer PostgreSql.app puis je compilerai quand j'aurai un peu plus de temps afin de voir ce que ça donne wink

#2 Re : Installation » [Résolu]Installation sous Mac OS X Maverick » 26/05/2014 23:01:20

Merci pour votre réponse rapide Gleu.

Je ne compte pas installer de serveur PostgreSql de prod sur un Mac, votre prochaine réponse déterminera si je compile ou non. Est-ce que compiler est si difficile que ça ? Avez-vous rencontrer de (grosses) difficultés ? n'ayant jamais compiler de serveur je m’appuierai sur votre expérience. La curiosité me dit "essaye ça fera un challenge de plus" ....

Merci pour le retour gleu.

#3 Installation » [Résolu]Installation sous Mac OS X Maverick » 26/05/2014 14:20:02

Crackerz
Réponses : 4

Bonjour,

Je suis sous MAC OS X Maverick et je voudrais savoir s'il y a une différence entre les différentes installation qui se présente pour un utilisateurs de MAC OS X :
  - Compiler postgreSql
  - PostgreSql.app
  - MacPort,Homebrew,...
  - enterpriseDB

Que me conseillez-vous dans qu'elle situation ?

Merci.

#4 Re : Général » Les index et l'optimisation » 25/04/2014 18:34:04

La définition de clef alternative que vous donnez ci-dessus est celle que je donne à clé secondaire.

"Le terme de secondaire n'est pas standard. La littérature utilisera le terme de clés candidates pour désigner tous les identifiants d'une table. Un identifiant secondaire est donc une clé candidate non primaire."

#5 Re : Général » Les index et l'optimisation » 25/04/2014 14:19:43

en tout cas, de ce que je comprends de votre explication, vos clés secondaires n'ont aucune existence du côté du SGBD. C'est juste une clé unique, qui est proche d'une clé primaire mais pas identique.

Oui c'est bien ça ! Dans un ouvrage que j'ai lu il déclarer les clés secondaire à l'aide du mot clé "UNIQUE" mais je ne sais pas si cette même notion est repris dans PostgreSql. Certains SGBDR y dépose un index non nécessairement unique ce qui reviens à ce que vous avez compris.

#6 Re : Général » Les index et l'optimisation » 25/04/2014 01:13:55

Merci c'est noté smile

J’appelle clé secondaire ou clé candidate non primaire un identifiant qui aurait pu être primaire mais ne l'ai pas "immédiatement". Un exemple :
CREATE TABLE T1(
    idT1   not null primary key,
    ....
    email  not null UNIQUE
);
Suis-je entrain de confondre différentes notions ?

#7 Re : Général » Les index et l'optimisation » 24/04/2014 02:19:56

Merci gleu pour votre réponse.

Ça peut être utile. Tout dépend du cas.
C'est quoi un index secondaire ?

Pourriez-vous me dire dans quel contexte vous jugez cela nécessaire ? (Je n'ai pas parler d'index secondaire).

Encore une fois, ça dépend. Si vous avez vingt lignes de nom/prénom, ça ne servira à rien. Si vous en avez 20 millions, ça devient intéressant... et encore, ça dépend des requêtes.
Quant au type, vous n'avez pas le choix : Btree.

Ok je ne pensai pas qu'un index n'étais pas bénéfique qu'à partir de même plus d'un million d'entrée.

Merci pour les autres réponses, je vais suivre votre lien.

#8 Général » Les index et l'optimisation » 23/04/2014 13:51:17

Crackerz
Réponses : 9

Bonjour,
Après une bonne lecture de la documentation j'ai quelques questions à propos de l'optimisation via notamment les index.

1)Lorsque je créer une clé primaire ou secondaire un index unique de type B-tree est créer automatiquement. Les clé étrangère doit-elle
porter un index explicitement pour accélérer les jointures ?

2)Je voudrai faire des recherches sur des prénoms,nom dans ma base de donnée dois-je y déposer un index, si oui de quel type me conseillez-vous ?

3)La recherche plein texte est utile uniquement dans le cas ou l'utilisateur fait de la recherche avec des mots clés ?

4)Un système utilisant l'auto-complétion doit-il être porteur d'un index particulier sur les colonnes parcourut ?

5)Un dernier conseil pour la route ?

Merci.

#10 Re : Général » [Résolu]Auto-incrémentation » 11/04/2014 18:08:23

Merci tout est plus claire smile

Une dernière question sur l'auto-incrémentation.
Si je veux qu'un attribut s'auto-incrémente en fonction d'un autre, une des solutions est de passer par les trigger ? Prenons un exemple courant, celui des Factures. Nous avons deux attributs : FactureId et ClientId il faut que les numéro de FactureId soit séquentielle est s'incrémente donc en fonction du Client.
Merci.

#11 Re : Général » [Résolu]Auto-incrémentation » 11/04/2014 01:02:03

Merci rjuju smile
Pourriez-vous m'indiquer ce que vous appelez une séquence ?

#12 Général » [Résolu]Auto-incrémentation » 10/04/2014 23:57:54

Crackerz
Réponses : 7

Bonsoir,

Pour gérer l’auto-incrémentation d'une clé primaire est-il préférable de faire cela avec un Trigger ou bien en utilisant un champ de type Serial ? Pourquoi ?

Merci smile

#13 Re : Général » Utiliser attribut composé » 07/04/2014 17:40:56

Merci Gaerel pour votre réponse !

Le type numTelephone n'est qu'une structure de découpage des données.
Il ne s'agit pas d'un table à part entière.
Elle peut être utilisée dans toute autre table sans aucune conséquence.

Cela voudrait dire que les trois numéros(si mentionner) seront stocker dans ma table Membre ? Donc accessible de cette façon :

Select (Telephone).fixe FROM Membre;

La seule chose compliquée dans votre exemple est de répondre au besoin : "il faut que l'utilisateur renseigne au minimum un des numéros"...

Par défaut je suppose qu'en procédant ainsi les valeurs sont facultatifs ?
Avez-vous une autres méthodes pour gérer les attributs composé ? Si vous me dîtes que la meilleur des solutions est de les dissocier comme sur mon premier exemple je m'y contenterai smile

Merci à vous !

#14 Général » Utiliser attribut composé » 07/04/2014 15:25:36

Crackerz
Réponses : 2

Bonjour,

Je me pose une question vis-à-vis de la gestion des attributs composé sur postgresql. Prenons l'exemple de l'attribut
Téléphone
   Mobile
   Fax
   Fixe
(il faut que l'utilisateur renseigne au minimum un des numéros ). La première méthode est de tous simplement désagréger l'attribut composé on obtient donc ceci : Membre(id,nom,prenom,mobile,fax,fixe,....);
L'autre méthode que je vois est de faire un :

    Create type numTelephone AS (
           Fixe         char(10),
           Portable   char(10),
           Fax          char(10)
    );
    Create Table Membre(
           .....
           Telephone    numTelephone
    );

Cependant, si j'utilise le type numTelephone sur un autre table disons les clients ( au hasard ), est-ce que cela mélangera les numéros des membres ?

Si vous avez d'autre conseil je prend smile

Merci.

Pied de page des forums

Propulsé par FluxBB