Clé primaire VARCHAR

Bonjour,

Je suis débutant en BDD et j'essaye de mettre en place ma première base.
J'ai donc modélisé ma base en suivant le tutoriel MERISE en commencant par le dictionnaire des données jusqu'au MLD.
Je suis actuellement à l'étape de création des tables.
J'ai une table avec comme clé primaire un VARCHAR et j'ai remarqué que je n'arrivai pas à la faire correspondre avec mes autres clé (primaires et secondaires) qui sont des entiers (int).(quand je met le type de ma clé en VARCHAR, toutes mes clé deviennent des VARCHAR)

Est-il possible de le faire ?

Merci d'avance pour vos réponse
Cordialement,
Antoine

Attention, Il est recommandé pour des questions de performances de ne pas utiliser de clé primaires en varchar.

Un int auto incrément (IDENTITY( 1, 1 ) ) sous sql server est conseillé pour limiter les soucis d'insertion en base et une amélioration des performancse de jointures de tables.

SQLPro à écrit un billet sur la gestion de clé primaires en BDD

Cordialement,
Lyche

Cela veut dire que même si cette donnée VARCHAR sera obligatoirement unique, il faudrait utiliser un entier comme clé primaire pour des raisons de performances ?

Citation:

---

Envoyé par antoine2641

Cela veut dire que même si cette donnée VARCHAR sera obligatoirement unique, il faudrait utiliser un entier comme clé primaire pour des raisons de performances ?

---

c'est exactement ça.
Un Entier nécessite moins de ressource pour le moteur sgbd qu'un caractère. Question d'encodage.

je t'invite à lire ce papier de SQLPro pour la gestion des clé-primaires.

http://sqlpro.developpez.com/cours/clefs/

Citation:

---

Envoyé par antoine2641

Cela veut dire que même si cette donnée VARCHAR sera obligatoirement unique, il faudrait utiliser un entier comme clé primaire pour des raisons de performances ?

---

Non. La solution "clés primaires de type INT" est plus générique mais ce n'est que la recommandation. I.e. "int identity" crée les problèmes pour les BDD distribuées. En transactionnel (OLTP) "clés primaires de type GUID" pourras être une bonne solution. A voir les cas particuliers.

D'accord c'est noté.
Merci pour le lien, je ne le trouvai pas.:ccool:

Merci et a bientôt sur db3 !:D

Citation:

---

Envoyé par Serguei_TARASSOV

Non. La solution "clés primaires de type INT" est plus générique mais ce n'est que la recommandation. I.e. "int identity" crée les problèmes pour les BDD distribuées. En transactionnel (OLTP) "clés primaires de type GUID" pourras être une bonne solution. A voir les cas particuliers.

---

Le Guid doit être utilisé comme référence de ligne, jamais comme Clé primaire. Si tu as des soucis avec les int identity c'est que tu as des soucis de conceptions de BDD.

Citation:

---

Envoyé par Lyche

Le Guid doit être utilisé comme référence de ligne, jamais comme Clé primaire.

---

Explications ?

Citation:

---

Si tu as des soucis avec les int identity c'est que tu as des soucis de conceptions de BDD.

---

Confirmations ?

Citation:

---

Envoyé par Serguei_TARASSOV

Explications ?

---

Un Guid est composé de caractère alpha-numérique. Hors il est évident et reconnu qu'un int est plus facilement géré, moins consommateur de ressources et moins gourmand en espace disque qu'un varchar( 36 ). (puisqu'un guid est géré dans un varchar(36)

Citation:

---

Confirmations ?

---

En 7années de bases de données dont 5 en SQL Server je n'ai jamais eu de soucis dans mes bases liées à une utilisation de clé primaire en Int, Si tu gères tes FK comme il faut et modélise clairement tes bases. Que tes processus ne sont pas en permanence en train de supprimer ton identity, tu ne devrais jamais avoir de soucis avec tes clé primaires gérées en Identity.
Si tel n'est pas le cas, je crois que tu peux changer ton "Expert SQL Server".

Edit : Si mes propos ne te suffisent pas, je t'invite à lire cette réponse de Elsuket, DBA et MVP Microsoft concernant la gestion des clé primaires.

http://www.developpez.net/forums/d92...n/#post5209771

Citation:

---

Envoyé par Lyche

Un Guid est composé de caractère alpha-numérique. Hors il est évident et reconnu qu'un int est plus facilement géré, moins consommateur de ressources et moins gourmand en espace disque qu'un varchar( 36 ). (puisqu'un guid est géré dans un varchar(36)

---

Non, c'est faux.
Voir le doc SQL Server (stockage physique) + l'optimisation sur les colonnes guid.
Voir à quoi sert la fonction NEWSEQUENTIALID()
Fais aussi les tests de perf "int vs guid"

Citation:

---

En 7années de bases de données dont 5 en SQL Server je n'ai jamais eu de soucis dans mes bases liées à une utilisation de clé primaire en Int, Si tu gères tes FK comme il faut et modélise clairement tes bases. Que tes processus ne sont pas en permanence en train de supprimer ton identity, tu ne devrais jamais avoir de soucis avec tes clé primaires gérées en Identity.
Si tel n'est pas le cas, je crois que tu peux changer ton "Expert SQL Server".

---

Désolé, je ne vois pas la confirmation dans cette paragraphe.
As tu l’expérience sur les produits OLTP installés sur plusieurs nœuds dont le nombre est dépendant du client ? Comment propose tu résoudre les conflits des valeurs i.e. lors de la réplication ?

Citation:

---

Envoyé par Serguei_TARASSOV

Non, c'est faux.
Voir le doc SQL Server (stockage physique) + l'optimisation sur les colonnes guid.
Voir à quoi sert la fonction NEWSEQUENTIALID()
Fais aussi les tests de perf "int vs guid"



Désolé, je ne vois pas la confirmation dans cette paragraphe.
As tu l’expérience sur les produits OLTP installés sur plusieurs nœuds dont le nombre est dépendant du client ? Comment propose tu résoudre les conflits des valeurs i.e. lors de la réplication ?

---

j'ai justement placé un liens vers une explication d'un MVP qui contredit clairement tes propos. Mais continue à faire des trucs pareils, j'aurai toujours du boulot :)

Cordialement,
Lyche

Jamais de la vie un GUID est stocké sous forme de VARCHAR(36) !

Et jamais de la vie il contient des caractères alpha-numériques !

Il s'agit d'un nombre, tout ce qu'il y a de plus nombre, au détail près qu'il est représenté en hexa, d'où la présence de lettres. Mais en aucun cas il est stocké dans un varchar !

C'est un INT(128) -sur 16 octets- sur lequel les opérations arithmétiques sont interdites (puisqu'il n'a pour vocation que d'être identifiant, en aucun cas pour faire des calculs).

Sur le GUID. C'est du binaire pur comme stockage.
La génération est presque aussi rapide que du INT / BIGINT autoincrémenté...
Mais :
1) le volume de stockage est double à quadruple du BIGINT / INT
2) utilisé dans un index CLUSTERED c'est bien pire :
2.1) cela augmente le volume de tous les index non clustered qui doivent référencer cette valeur
2.2) cela fragmente terriblement la table.

À me lire : http://blog.developpez.com/sqlpro/p7...ent_le_verdict

Il y a quelques années, devant procéder à un audit sur une base de données de sécurité sociale pour les handicapés, toutes les tables ayant des GUID, les performances étaient catastrophiques....
Bilan des opérations : refonte du modèle, juste 3 mois après mise en route !!!!

A +

Serguei: rien ne vous oblige à définir votre Colonne Guid comme la clé primaire... vous pouvez la laisser en temps que clé candidate ce qui évite de propager ce lourd fardeau dans vos index NON CLUSTER....

SQLpro, iberserk, merci pour les retours.

Bon, je remonte le test qu j'ai fait en 2002. Voici l'adaptation
Primary key en OLTP : "int" ou "guid" ?

En terme de perf il n'y a pas de dégradation toujours en 2012 ;)

En terme de stockage juste quelques remarques :
- le volume de stockage de "int" est double par rapport de "smallint" et quadriple par rapport de "tinyint" :)
- en mode compression la différence devient négligeable
- pas de fragmentation avec newsequentialguid()
- on est en OLTP, la volume n'est pas significative. L’évolutivité et maintenabilité de solutions N-tiers sont plus importants. Par contre la conception BDD concerne la CRUD en 80%.

Les gars, regardez bien les tables SAP R3. Il y a des clés varchar(nn) partout :mrgreen: Faut voir ça coté dév aussi et non DBA seulement.

Travaillant dans une boite d'intégration d'ERP je peux te dire que c'est en général une catastrophe! et pas que les bases les langages d'accès aux données aussi (bonjour X++)

Perso, je travail souvent avec ORM (i.e. NHibernate) ou fais l'audit de tels projets. Au point de vue DBA, SQL généré n'est pas parfait. Mais au point de vue plus globale en 95% des cas SQL est suffisamment bien et dans le reste 5% il est possible d'en optimiser à la main. La perfection est l'ennemie du bien :lol:

Citation:

---

Perso, je travail souvent avec ORM (i.e. NHibernate) ou fais l'audit de tels projets. Au point de vue DBA, SQL généré n'est pas parfait. Mais au point de vue plus globale en 95% des cas SQL est suffisamment bien et dans le reste 5% il est possible d'en optimiser à la main

---

Tout a fait daccord....

Je parle surtout de batchs lancés depuix AX en code client avec un X++ qui ne sait faire des traitement que via des curseurs SQL...

Citation:

---

Envoyé par iberserk

Je parle surtout de batchs lancés depuix AX en code client avec un X++ qui ne sait faire des traitement que via des curseurs SQL...

---

Oui, c'est horrible j'imagine, mais n'est pas spécifique à X++. Plusieurs développeurs font le traitement côté client des curseurs/recordsets ADO.Net ou "curseurs" - les listes des objets retournés par ORM puisque ils ne savent pas SQL tout simple. C'est la question de "savoir faire" plutôt et cela existe depuis les premières SGBD client-serveur...