Structure base de données

Bonjour à tous,
Alors voilà je développe des applis en C# et forcément je suis amené à utiliser des bases de données.
J'avais pris certaines habitudes et je ne sais pas pourquoi (sûrement parce que j'ai jamais vraiment appris les SGBD) je me suis remis pas mal en question et j'ai donc une question de débutant.
Prenant 3 tables et faisons simple:
Table FOURNISSEURS, colonnes NOM, LOCALITE
Table TYPEOUTIL, colonnes NOMOUTIL,PRECISION
Table de jonction OUTILS, colonnes IDENTIFICATION,FOURNISSEURS,TYPEOUTIL

J'ai pour habitude de systématiquement mettre une colonne ID sur mes tables, avec une clé primaire auto-incrémentée et donc faire référence à cet ID dans la table de jonction (je pense que vous voyez le truc :-) )
Mais est-ce bien nécessaire?
En fait, si dans cette table OUTILS, je fais référence directement à NOM et NOMOUTIL qui sont uniques, c'est quoi le problème?
Est-ce que c'est moins performant, plus difficile à maintenir, plus de place en mémoire, etc...

En fait si je suis amené à poser cette question, c'est parce que je dois fusionner 2 bases et les auto-incréments me posent un problème du coup, mais je préfère avoir la réponse à ma 1ère question avant d'aller plus loin. Je ne voudrais pas remettre en question une éventuelle bonne pratique pour un soucis ponctuel.

Merci d'avance.

Citation:

---

Envoyé par gadsweb

Bonjour à tous,
Alors voilà je développe des applis en C# et forcément je suis amené à utiliser des bases de données.
J'avais pris certaines habitudes et je ne sais pas pourquoi (sûrement parce que j'ai jamais vraiment appris les SGBD) je me suis remis pas mal en question et j'ai donc une question de débutant.
Prenant 3 tables et faisons simple:
Table FOURNISSEURS, colonnes NOM, LOCALITE
Table TYPEOUTIL, colonnes NOMOUTIL,PRECISION
Table de jonction OUTILS, colonnes IDENTIFICATION,FOURNISSEURS,TYPEOUTIL

J'ai pour habitude de systématiquement mettre une colonne ID sur mes tables, avec une clé primaire auto-incrémentée et donc faire référence à cet ID dans la table de jonction (je pense que vous voyez le truc :-) )
Mais est-ce bien nécessaire?

---

Non

Citation:

---

En fait, si dans cette table OUTILS, je fais référence directement à NOM et NOMOUTIL qui sont uniques, c'est quoi le problème?
Est-ce que c'est moins performant, plus difficile à maintenir, plus de place en mémoire, etc...

---

OUI, OUI, OUI !

Cela rend aussi les requêtes plus complexes. Donc c'est pas indispensable.... C'est juste nécessaire !

A +

Ok, merci pour la réponse.
Alors si je comprends bien, je dois maintenir mes ID de manière générale.
J'ai donc un autre problème du coup...
J'ai des bases identiques de structure sur plusieurs appareils en SQL server compact.
J'ai donc des champs auto-incrémentés dans chaque base.
Supposons :
Appareil A, Table TEST, ID (auto-incrément)=2, LABEL=ABCD
Appareil B, Table TEST, ID (auto-incrément)=8, LABEL=ABCD
Je dois donc fusionner mes tables sur un serveur SQL, pour vider les appareils (pas trop puissants) et faire des backups.
Sur mon serveur, j'aimerais donc une table TEST, ou par exemple l'ID est 5 pour désigner le LABEL=ABCD (initialement ID 2 sur appareil A et ID 8 sur le B).
Comment je fais pour "harmoniser" les ID, sachant que dans la table de jonction, je dois donc changer mon 2 en 5 et mon 8 en 5.
A cet instant ma seule idée (je passe par du C#), c'est de regarder si le label existe, dans ce cas je récupère l'id et j'update toutes les lignes concernées de toutes les tables, et s'il n'existe pas, ben je l'insère et idem j'update...
Ca me parait pas très compliqué mais pas très efficace non plus comme truc, mais bon je vois rien d'autre avec mes connaissances.

J'ai essayé d'être clair et un peu lourd :-), j'espère que çà l'est (clair évidemment)

Merci d'avance.

Il faut que vous identifiez vos tables de référence et que vous décidiez d'un référentiel commun.

A +

Je ne pense pas que cela soit possible. Je rentre un peu plus dans le concret.
Des opérateurs possèdent des terminaux portables lecteurs code barre.
Ils travaillent sur des palettes qui possèdent entre autres un N° d'identification et une date.
Chaque palette est composée de plusieurs bacs qui possèdent un N° également et une référence.
Chaque bac est composée de pièces qui possèdent on N° de lot.
Ils travaillent sur la même palette, le même bac et j'enregistre donc chaque scan. Pas de connexion à un serveur.
Donc quand ils démarrent une palette, j'ai un ID différent dans chaque base, idem pour les bacs.
Voilà le problème que je ne sais pas traiter quand je dois fusionner mes 2 bases.

Bonjour,

Attribuez un identifiant propre à chaque lecteur CàB + un identifiant palette , carton etc...
Puis quand vous déversez dans la base commune attribuez un nouvel identifiant comme id primaire, et stockez l'identifiant lecteur + l'id d'origine comme id secondaire

Citation:

---

Envoyé par gadsweb

Je ne pense pas que cela soit possible. Je rentre un peu plus dans le concret.
Des opérateurs possèdent des terminaux portables lecteurs code barre.
Ils travaillent sur des palettes qui possèdent entre autres un N° d'identification et une date.
Chaque palette est composée de plusieurs bacs qui possèdent un N° également et une référence.
Chaque bac est composée de pièces qui possèdent on N° de lot.
Ils travaillent sur la même palette, le même bac et j'enregistre donc chaque scan. Pas de connexion à un serveur.
Donc quand ils démarrent une palette, j'ai un ID différent dans chaque base, idem pour les bacs.
Voilà le problème que je ne sais pas traiter quand je dois fusionner mes 2 bases.

---

Autre solution, si vous pensez avoir 1000 terminaux au maximum dans la vie de l'entreprise alors constituez vos auto-incréments avec IDENTITY de la manière suivante sur chaque table de chacun des postes :

Code:

---

IDENTITY(N, 1000)

---

N étant un numéro séquentiel attribué à chaque terminal.
Ainsi le terminal n°1 démarrera ses IDENTITY à 1 avec un pas de 1000, le 2e à 2 avec un pas de 1000, etc...
Au final vous n'aurez jamais de télescopage de clef lors de la concentration des données et serez toujours en mesure de savoir de quel terminal vient telle ou telle information en utilisant l'opérateur modulo (%).

A +

Bonjour et merci de vos réponses mais soit j'ai pas bien compris les réponses,soit j'ai mal exposé le problème, mais les solutions apportées ne résolvent pas mon problème.
Conserver une trace du terminal c'est pas un soucis, je stocke son nom Windows.
Maintenant je reprends le problème sur juste un exemple.
Le terminal A enregistre un nouveau bac dont le nom est par exemple ABCD. Il lui attribue l'iD 5. Dans ma table de jonction du terminal A, je fais donc référence à l'ID 5 lorsque je parle de mon bac.
Le terminal B enregistre également ce bac comme nouveau (pas de connexion entre les 2 terminaux). Il lui attribue l'ID 10 et le nom du bac est toujours ABCD. Dans ma table de jonction du terminal B, je fais donc référence à l'ID 10 lorsque je parle de mon bac.
Maintenant, lorsque je vais fusionner, j'aurai donc le bac ABCD qui portera dans certains cas l'ID 5 et dans d'autres l'ID 10. Et dans la table de jonction, pareil, certains enregistrements feront référence à un ID 5 et d'autres à un ID 10, qui désigneront en fait le même bac ABCD. Imaginez avec 10 terminaux...

Je souhaiterais donc que dans ma base principale, pour parler du bac ABCD, je fasse référence à un ID unique (peu importe que ce soit un nouveau ou un existant) et que tous les enregistrements faisant référence au bac ABCD aient cet ID unique comme référence.

Je ne voudrais pas abuser de votre patience, mais je voudrais faire quelque chose de robuste...

Merci d'avance

dans ce cas la colonne contenant ABCD doit être une clef alternative dans toutes les bases et vous devez fusionner les lignes à l'arrivée avec MERGE.

A +

Donc vous devriez avoir :

- Une table des bacs
- Une table des terminaux
- Une table représentant la relation bacs-terminaux, éventuellement qualifiée par une date et l'ID de ce bac sur ce terminal

Dès lors ce que propose SQLPro devrait s'implémenter relativement simplement.

@++ ;)

Bonjour,

Avez vous essayer de mettre vos clef primaire en UniqueIdentifier ? (Guid en Dotnet).

vos clef seront unique sur toute les bases de données, et fusionné toute les bases dans une seul base est alors très simple (juste à copier les lignes).

Si vous ne pouvez pas modifier vos base de données, mais que vous pouvez modifier votre base de donnée central, un simple champs en plus vous permettra alors pour la synchro de filtrer dessus (BASENAME par exemple).
bien sur vous devrez faire un clef composé sur votre pk en int et ce champs dans la base central.

Bonne chance.

Citation:

---

Envoyé par aserf

Bonjour,

Avez vous essayer de mettre vos clef primaire en UniqueIdentifier ? (Guid en Dotnet).

---

ça c'est juste une grosse merde infâmes !

A +

On ne sera définitivement jamais d'accord sur le sujet ! :D