Discussion :

[etiennegaloup]

Bonjour,

je cherche a developper une base de donnees compte pour gérer mes comptes personnel.

Cette base de données est constitué d'une table transaction dont la définition est :

Code :

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

1
2
3
4
5
6
7
8
create table transac (
	transId INT PRIMARY KEY identity(1,1),
	transDate DATETIME DEFAULT GETDATE() not null,
	transOrdre VARCHAR(30) not null,
	transType CHAR(2) not null,
	transOper VARCHAR(6) not null,
	transMontt DECIMAL(5,2) not null
)

J'aimerai associé à chaque transaction une catégorie (Restaurant, Auto, Alimentation....) . Ces catégories sont prédéfinie, et le logiciel faisant l'interface avec la base de données permettra d'en ajouter ou d'en supprimer.
J'aimerai savoir si je dois définir une table catégorie regroupant toutes les catégories et donc une table relation définissant la relation entre la transaction et la catégorie
ou si je dois définir catégorie comme attribut de la table transaction.

Merci pour vos réponses.
Ciao.

[Cybher]

Salut,

je sais pa si c'est la meilleure solution mais moi personellement je ferais ceci:
-une table catégorie(id, nom)
- et je rajoute l'id catéorie dans la table transaction.

cela sera moins lourd à stocker que le nom à chaque fois.
si un jour tu veux rajouter une catégorie ou modifier le nom de la catégorie, tu n'a qu'a modifier une ligne dans cette table.

Après ce n'est que mon avis.

Bon courage

[etiennegaloup]

Oui je suis tout à fait d'accord avec toi, je pense aussi que c la meilleure solution.
En fait ce que je vais faire, c utiliser une table transaction, une table categorie et une troisième table pour gérer les relations entre transaction et categorie,
qu'en penses-tu ?

[Cybher]

c'est comme tu veux.

Moi personnellement, je n'aurais pas créer une 3e table pour la relation.
Je préfère mettre l'id correspondant à la catégorie dans la table création.
Cela rend les requêtes plus simple je trouve (tu travailles sur un table de moins).

après c'est un choix. je connais pas toute ton appli.

bye

[etiennegaloup]

Bah là mon appli est très simple, il y a juste ce que je t'ai dit.
Mais sinon dans le cas d'une base de données relationnelle un peu plus consitante, t d'accord qu'il faut utiliser une table relation entre deux autres tables ?
Par exemple, j'ai une table etudiant, une table livre et une table qui fait la relation entre ces deux tables ayant pour attribut l'id etudiant, l'id livre et la date d'emprunt...

Et sinon question à deux francs, quand utilise-t-on une structure tel que décrite ci-dessus avec trois tables et quand utilise-t-on une structure simplifiée sans troisième table.

[TheLeadingEdge]

Bonsoir,

Moi personnellement, je n'aurais pas créer une 3e table pour la relation.
Je préfère mettre l'id correspondant à la catégorie dans la table création.

+1

Si 1 transaction ne peut être que d'1 seule catégorie tu vas te compliquer la vie avec 1 table d'assoce.

cf :
http://www.developpez.net/forums/vie...light=#2087663 pour répondre à ta question.

A +,

[Médiat]

Tout dépend de la finesse que tu veux atteindre, et comment tu veux l'atteindre, c'est à dire quelle définition tu donnes à "Transaction" :

Prends l'exemple d'un achat payé par chèque dans un supermarché, cet achat concerne de l'Alimentation, des produits d'entretien, Une télévision

• 1) Gestion grossière et simpliste :
  [list:85e51c8c1d]une transaction = un paiement donc ici un chèque, tu choisis la catégorie principale (ici la télévision qui entre dans catégorie "Bien d'équipement"
  Inconvénient : tu ne sais plus quel est le prix dans chaque catégorie
  Avantage : rapidité de saisie (mais allez vite pour saisir n'importe quoi ...)
  Méthode : id_catégorie dans la table transaction.

[/list:u:85e51c8c1d]

• 2) Gestion fine et simpliste :
  [list:85e51c8c1d]une transaction = un paiement pour une catégorie, dans l'exemple précédent, il y aurait 3 transactions (Alimentation, Entretien, Equipement)
  Inconvénient :
  [list:85e51c8c1d]le paiement par chèque n'existe pas en tant que tel, la réconciliation avec la banque est plus difficile.
  Saisie plus compliquée (il faut découper son chèque (avec le ticket de caisse))
  Le glissement sémantique, la table des transactions est devenue la table des bout de transactions découpées par catégorie
  Certaines informations sont dupliquées (Date de la transaction, N° du Chèque, ...)

Avantage : on a tous les détails
Méthode : id_catégorie dans la table transaction.[/list:u:85e51c8c1d][/list:u:85e51c8c1d]

• 3) Gestion fine :
  [list:85e51c8c1d]Une transaction = un paiement (un chèque ici)
  Une transaction est découpée par catégorie grace à une association entre Catégorie et Transaction.
  Avantage : tu conserves toutes les informations au niveau le plus fin, tout en conservant la sémantique de tes entités
  Inconvénient : Saisie plus compliquée (il faut découper son chèque (avec le ticket de caisse))
  Méthode :
  [list:85e51c8c1d]Table Transaction (IdTransaction, DateTransaction, Montant, ModePaiement, etc.
  Table Catégorie (IdCatégorie, Libellé, etc...
  Table Affectation (IdTransaction, IdCategorie, Montant)

Le montant dans la transaction ne sert qu'à accélèrer certains traitements, il peut être avantageusement remplacé par le calcul systématique de la somme des montants des Affectations[/list:u:85e51c8c1d][/list:u:85e51c8c1d]

[etiennegaloup]

Bonjour,

et bien je suis tout à fait d'accord avec, toi. La troisième partie me convient au mieux, mais comme le dit TheLeadingEdge à


http://www.developpez.net/forums/vie...light=#2087663

ceci est valable dans le cas où j'ai une relation n<->n. Moi je pensais plutôt initialement à une relation 1<->1.
Alors que contrairement à l'exemple que Mediat vient d'exposer ce serait plutôt une relation n<->n.

Mais j'y vois déjà beaucoup mieux, à moi maintenant de choisir la structure qu'aura ma base de données.

Merci à tous.
A bientôt
Ciao