PRIMARY KEY ET PERSITED AVEC FOREIGN KEY

Version imprimable

13/05/2014, 13h17
Anthony_C

PRIMARY KEY ET PERSITED AVEC FOREIGN KEY

Bonjour,

Message supprimer ( ne correspond plus à la situation actuel: voir plus bas)
13/05/2014, 13h44
Anthony_C

Si quelqu'un connait une solution à ce problème, merci de la partager ;)
13/05/2014, 14h30
aieeeuuuuu

Bonjour,

Quand vous créez votre table Contact, vous ne spécifiez pas de longueur pour la colonne refOwner. C'est donc la longueur par défaut, à savoir 1, qui est prise en compte.
Comme dans la table Customer, la clef primaire est en nvarchar(25), vous ne pouvez pas créer la contrainte d'intégrité référentielle, d'où votre message d'erreur.

Cependant, pourquoi du NVARCHAR et pas simplement du VARCHAR. Globalement, ces types sont à éviter pour les clef primaires : Votre clef primaire en NVARCHAR(25), c'est jusqu'à 52 octets ! Vous devriez créer des clefs primaires numériques (par exemple INT, 4 malheureux octets) auto-incrémentées, et garder votre colonne en clef candidate (avec une contrainte d'unicité)
Car en plus des problèmes de performances évoqués, comment ferez vous si un Customer change de nom ?
13/05/2014, 14h47
Anthony_C

Merci pour votre réponse constructive, j'avais effectivement pas pensé à un changement de nom :roll:

et comme solution je viens de prendre la décision de fusionner la table client et fournisseur, un client pouvant être une personne physique ou une société, seul deux champs supplémentaire doivent être ajoutés: isSupplier (estFournisseur) et le numéro de client attribuer par un fournisseur à la personne pour qui le logiciel est destiné.

Cela rend les choses plus générique et apporte moins de redondance ( un fournisseur pouvant être un client).

Ceci simplifie donc le problème, j'ai décidé de générer la référence avec le logiciel et plus sql serveur afin de mieux gérer les différentes contraintes comme le fait que le client soit une société et non une personne physique.

Pour les nvarchar, c'est une personne qui ma confier qu'il avait une meilleur utilité. j'ai trouvé ce lien qui en parlait sur le forum:
http://www.developpez.net/forums/d11...char-nvarchar/

J'en ai déduis qu'ils prenaient moins de place que les varchar et avaient un potentiel plus grand, ce pourquoi je les emplois.

Pouvez-vous me dire si mon raisonnement est correcte, je suis débutant ceci étant mon premier logiciel :D

Voici la création de la table maintenant:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
CREATE TABLE [dbo].[customerSupplier](
	[pkCustomerSupplier] [int] IDENTITY(1,1) NOT NULL,
	[reference] [varchar](8) NOT NULL,
	[name] [nvarchar](20) NULL,
	[firstname] [nvarchar](20) NULL,
	[societyName] [nvarchar](25) NULL,
	[customerNumber] [nvarchar](20) NULL,
	[tva] [nvarchar](15) NULL,
	[gsm] [nvarchar](25) NULL,
	[phone] [nvarchar](25) NULL,
	[site] [nvarchar](50) NULL,
	[mail] [nvarchar](50) NULL,
	[note] [nvarchar](255) NULL,
	[isSociety] [bit] NOT NULL,
	[isSupplier] [bit] NOT NULL,
 CONSTRAINT [PK_CustomerSupplier] PRIMARY KEY CLUSTERED 
(
	[pkCustomerSupplier] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY],
UNIQUE NONCLUSTERED 
(
	[reference] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
 
GO
 
SET ANSI_PADDING OFF
GO

13/05/2014, 15h19
aieeeuuuuu

Citation:

Envoyé par Anthony_C

et comme solution je viens de prendre la décision de fusionner la table client et fournisseur, un client pouvant être une personne physique ou une société, seul deux champs supplémentaire doivent être ajoutés: isSupplier (estFournisseur) et le numéro de client attribuer par un fournisseur à la personne pour qui le logiciel est destiné.

Cela rend les choses plus générique et apporte moins de redondance ( un fournisseur pouvant être un client).

Je ne connais pas vos règles de gestion, mais il me semble que vous êtes dans un cas d'héritage.

Citation:

Envoyé par Anthony_C

Pour les nvarchar, c'est une personne qui ma confier qu'il avait une meilleur utilité. j'ai trouvé ce lien qui en parlait sur le forum:
http://www.developpez.net/forums/d11...char-nvarchar/

J'en ai déduis qu'ils prenaient moins de place que les varchar et avaient un potentiel plus grand, ce pourquoi je les emplois.

Pouvez-vous me dire si mon raisonnement est correcte, je suis débutant ceci étant mon premier logiciel :D

Non, vous pouvez stocker moins de caractères, justement car nvarchar prend plus de place que varchar.... deux fois plus en fait : 2 octets par caractère contre 1 seul octet en varchar. Reste à voir donc le jeu de caractères que vous allez devoir stocker. mais si votre base n'est pas multilingue, à priori le varchar suffit.
13/05/2014, 15h42
Niklosus

Bonjour,

Citation:

Envoyé par aieeeuuuuu

Je ne connais pas vos règles de gestion, mais il me semble que vous êtes dans un cas d'héritage.

Une seule table [customerSupplier] risque de ne pas être très intuitif pour les utilisateurs de cette table. Et vous risquez de complexifier les requêtes qui vont aller récupérer les données sur cette table.
Vous pouvez envisager d'avoir des tables [Customers] et [Suppliers] qui réfèrencent une table [Contacts].
13/05/2014, 15h48
Anthony_C

1 pièce(s) jointe(s)

merci pour la précision sur le nvarchar je comprend beaucoup mieux maintenant ;)

Voici mon schémas actuel: je l'ai placé en pièce-jointe.

Il s'agit d'une application de gestion d'un commerce d'indépendant dans le secteur horticole.
Il peut y enregistrer fournisseur et client (l'un pouvant être l'autre). Un client peut être une société ou une personne physique tandis que un fournisseur est d'office une société.

J'ai ajouté dans la table isSociety et isSupplier pour différencier les fournisseur des clients et les société des personne physique.
Pour une société le nom est comparable au nom du client et les sigle au prénom du client.

J'ai lu ton lien vers l'héritage mais je vois pas bien comment l'héritage peut améliorer l'utilisation actuelle?
13/05/2014, 15h55
Anthony_C

reference sera un identifiant du client ou fournisseur qui sera utilisé sur les devis, facture,... afin d'avoir autre que l'id (int) simplement.
Le gérant en question a l'habitude d'utiliser les initiales des ces clients, je compte ajouter l'id pour rendre cela plus ''unique".

pour le numberCustomer, c'est le numéro attribuer au gérant chez un de ces fournisseur. Son numéro de client chez un fournisseur.

De le cas ou c'est une société, elle peut posséder plusieurs contacts.
13/05/2014, 16h16
Niklosus
Citation:

Envoyé par Anthony_C

Il peut y enregistrer fournisseur et client (l'un pouvant être l'autre).
- Comment allez vous faire si un fournisseur est également un client. Vous allez créer deux enregistrements dans la table [customerSupplier] ?
  L'héritage vous permet d'éviter cette redondance.
- La table [Contact] liste la personne physique à contacter chez le client ou chez le fournisseur ? Si oui, ce contacte peu-il être domicilié à une autre adresse ? si oui, il manque une relation entre la table Contact et Address.
13/05/2014, 16h21
Anthony_C

merci pour votre réponse,

j'ai placé un bool ( isSupplier, estFournisseur) afin de différencier les client des fournisseur. Je devrais ajouté isCustomer pour différencier correctement c'est juste :roll:

- un contact appartient à une société et ne possède pas d'adresse, ça peut être la secrétaire d'une entreprise ou un responsable de secteur, ect
13/05/2014, 16h26
Anthony_C

je vois pas bien comment un héritage pourrait mieux gérer cela :weird:
13/05/2014, 17h16
Niklosus

Citation:

Envoyé par Anthony_C

je vois pas bien comment un héritage pourrait mieux gérer cela :weird:

Tout dépend comment vous stockez un fournisseur qui est aussi client. J'ai cru comprendre dans votre 1er message que la valeur de la colonne [reference] est construite différemment pour un client (2 premières lettre nom + 1er prénom + id) et un fournisseur (2 première lettre société + id).
Si tel est le cas, une société qui est cliente et fournisseur sera stockée dans deux enregistrements distinct (car ils n'auront pas la même valeur [reference]). Donc les caractéristiques communes seront stockées 2 fois dans la table.
Dans ce cas, l'héritage vous permet de stocker ces caractéristiques communes une seule fois.
13/05/2014, 17h25
Anthony_C

Suite aux différentes remarques, j'ai modifier la bd, j'utilise à présent le schémas ci-dessus posté à 15h48.
j'ai ajouté isSupplier et isCustomer. ce sont des boll. si ils sont à true cela signifie que l'enregistrement est un client et un fournisseur.

Cette fiche unique me permet de disposer d'une id auto incrémenté unique pour chaque enregistrement donc la référence unique n'est plus obligatoire,
c'est plus pour afficher autre chose que 128 comme référence client sur un document. Le référencement, je compte le faire depuis le logiciel, actuellement
les initiales sont utilisés mais du coup des doublons peuvent exister.