Discussion :

[Anthony_C]

Bonjour,


Message supprimer ( ne correspond plus à la situation actuel: voir plus bas)

[Anthony_C]

Si quelqu'un connait une solution à ce problème, merci de la partager

[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 ?

[Anthony_C]

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

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

[Anthony_C]

Voici la création de la table maintenant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[aieeeuuuuu]

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.

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

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.

[Niklosus]

Bonjour,

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].

[Anthony_C]

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?

[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.

[Niklosus]

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.

[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

- 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

[Anthony_C]

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

[Niklosus]

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

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.

[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.