Stratégie de stockage d'informations issues d'un formulaire

Version imprimable

06/06/2018, 09h47
tipack

Stratégie de stockage d'informations issues d'un formulaire

Bonjour,

Dans le cadre d'un stage en entreprise je dois créer un formulaire dont certaines informations sont à conserver. Je vais donc créer une base de données mais j'ai quelques questions concernant son architecture :

- Est-il pratique de stocker de phrases comme des commentaires et des descriptions dans une BDD ou faut-il éviter le plus possible ?

- Doit-on privilégier le stockage d'une variable booléenne ou une jointure pour regrouper des infos ?
(Par exemple, j'ai des produits qui peuvent être chimiques ou non et donc deux tables : une générale contenant tous les produits et une contenant uniquement les information spécifiques aux produits chimiques.
Comment savoir si un produit est chimiques ? Créer un attribut booléen dans la table produit ou faire une jointure sur l'identifiant du produit dans les deux tables et voir si on a une ligne correspondante ?)

- Toutes les données d'un formulaire doivent-elle forcément être srockées dans la BDD ?
(A partir des données je créée en fait une fiche Word et certaines des informations ne sont pas utiles en dehors de cette fiche. Est-ce que c'est quand même mieux de les stocker dans la BDD ?)

- Doit-on plutôt calculer la moyenne ou la somme de plusieurs autres variables à chaque affichage par un utilisateur ou les stocker dans la BDD si on veut les afficher maximum 10 fois par an ?

- Doit-on créer un Id pour chaque table ou chercher plutôt une clé parmi les arguments existant ?

- Y-a-t-il un avantage énorme à utiliser Oracle plutôt que MySQL?

Voilà... ça fait beaucoup de questions mais j’espère avoir des réponses à quelques unes !
Merci d'avance !
06/06/2018, 10h41
aieeeuuuuu

bonjour,

Citation:

Envoyé par tipack

- Est-il pratique de stocker de phrases comme des commentaires et des descriptions dans une BDD ou faut-il éviter le plus possible ?

Sur le principe, pas de contre indication, mais parfois quelques précautions à prendre
Il faudrait un cas concret pour être plus précis.

Citation:

Envoyé par tipack

- Doit-on privilégier le stockage d'une variable booléenne ou une jointure pour regrouper des infos ?
(Par exemple, j'ai des produits qui peuvent être chimiques ou non et donc deux tables : une générale contenant tous les produits et une contenant uniquement les information spécifiques aux produits chimiques.
Comment savoir si un produit est chimiques ? Créer un attribut booléen dans la table produit ou faire une jointure sur l'identifiant du produit dans les deux tables et voir si on a une ligne correspondante ?)

Si les produits chimiques ont des propriétés que les autres produits n'ont pas, alors oui, table séparée pour mise en place d'un héritage.
sinon une colonne booléenne fait l'affaire.

Citation:

Envoyé par tipack

- Toutes les données d'un formulaire doivent-elle forcément être srockées dans la BDD ?
(A partir des données je créée en fait une fiche Word et certaines des informations ne sont pas utiles en dehors de cette fiche. Est-ce que c'est quand même mieux de les stocker dans la BDD ?)

Le principe est on ne peut plus simple : stockez ce dont vous avez besoin, ne stockez pas ce dont vous n'avez pas besoin...

Citation:

Envoyé par tipack

- Doit-on plutôt calculer la moyenne ou la somme de plusieurs autres variables à chaque affichage par un utilisateur ou les stocker dans la BDD si on veut les afficher maximum 10 fois par an ?

Là aussi un cas concret serait mieux, car il peut y avoir des cas particuliers, mais sur le principe, on ne stocke pas le résultat de calculs...
Et en cas de problème de performances, on avise (en fonction du SGBDR)

Citation:

Envoyé par tipack

- Doit-on créer un Id pour chaque table ou chercher plutôt une clé parmi les arguments existant ?

Il ne faut pas utiliser les données du SI comme clef primaire, mais préférer une clef générée par le système, la plus courte possible...

Citation:

Envoyé par tipack

- Y-a-t-il un avantage énorme à utiliser Oracle plutôt que MySQL?

vaste question, tout dépend de ce que vous faites...
06/06/2018, 13h14
escartefigue

Tout à fait d'accord avec ce qui précède,

Pour ce point particulier

Citation:

Envoyé par tipack

(A partir des données je créée en fait une fiche Word et certaines des informations ne sont pas utiles en dehors de cette fiche. Est-ce que c'est quand même mieux de les stocker dans la BDD ?)

Il faut peut être envisager un stockage en GED après numérisation du document word en plus du stockage de certains attributs dans la BDD.
11/06/2018, 15h00
arthur57

Citation:

Envoyé par escartefigue

Il faut peut être envisager un stockage en GED après numérisation du document word en plus du stockage de certains attributs dans la BDD.

L'avantage de garder ces informations en base de données serait aussi de pouvoir "re-générer" un document souhaité. Bien sur cela dépends du contexte.
13/06/2018, 12h57
Mat.M

Citation:

Envoyé par tipack

Est-il pratique de stocker de phrases comme des commentaires et des descriptions dans une BDD ou faut-il éviter le plus possible ?

cette question n'a pas de sens à l'heure des méga bases de données et du Big Data...
maintenant cela peut être utile de scinder du textes en plusieurs éléments distincts

Citation:

Envoyé par tipack

- Doit-on privilégier le stockage d'une variable booléenne ou une jointure pour regrouper des infos ?

une variable booléenne permettra des traitements bien plus rapide qu'une jointure.
De toute façon dans un programme informatique il faut toujours faire simple le plus possible

Citation:

Envoyé par tipack

(Par exemple, j'ai des produits qui peuvent être chimiques ou non et donc deux tables : une générale contenant tous les produits et une contenant uniquement les information spécifiques aux produits chimiques.

cela peut se faire par du code

Citation:

Envoyé par tipack

Comment savoir si un produit est chimiques ?

d'abord il faudrait définir ce qu'est un produit chimique..
quels sont les critères permettant de définir un produit chimique ou non.
de toute façon toute matière organique ou minérale peut subir des réactions physico-chimiques.

Dans un programme informatique toute chose doit être définie forcément et cela ne permet aucune ambigüité :mrgreen:

Citation:

Envoyé par tipack

- Y-a-t-il un avantage énorme à utiliser Oracle plutôt que MySQL?

Oracle est payant et les licences sont onéreuses
13/06/2018, 17h05
escartefigue

Citation:

Envoyé par Mat.M

Citation:

Envoyé par tipack

Y-a-t-il un avantage énorme à utiliser Oracle plutôt que MySQL?

Oracle est payant et les licences sont onéreuses

C'est vrai mais la question portait sur les avantages ;)

A part si vous disposez de la toute dernière version 8.0 de MySQL, les version antérieures sont restées au paléolithique du SQL : pas de CTE (et donc pas de requête récursive), pas de fonction OLAP, pas de jointure "FULL OUTER", gestion des verrous pauvre, pas de contrainte "CHECK", etc...
Alors que Oracle, comme les autres SGBD modernes proposent tout ça depuis bien longtemps ;)

EDIT : sauf erreur de ma part, il n'y a toujours pas de contrainte "CHECK" dans la V8 de MySQL, grosse lacune :(
13/06/2018, 17h56
Waldar

A priori il y a du mieux :
https://dev.mysql.com/doc/refman/8.0...alid-data.html
13/06/2018, 18h51
Mat.M

@escartefigue: ok autant pour moi alors ;)

Citation:

Envoyé par tipack

Dans le cadre d'un stage en entreprise je dois créer un formulaire dont certaines informations sont à conserver. Je vais donc créer une base de données mais j'ai quelques questions concernant son architecture :

- Est-il pratique de stocker de phrases comme des commentaires et des descriptions dans une BDD ou faut-il éviter le plus possible ?

Le stockage de textes en BDD ne pose pas particulièrement de problème.
Vous pouvez aussi considérer deux cas, si vous avez un volume important de données à stocker (à partir plusieurs centaines de milliers ou millions de lignes dans une table, selon le SGBD utilisé) :
1) Des textes à stocker sur une grande majorité des lignes de la table (par exemple, une description qui est systématiquement renseignée ou presque).
=> Vous stockez alors le texte dans la table principale.

2) Des textes à stocker sur une petite minorité de lignes de la table (par exemple un champ de formulaire pour un commentaire mais qui est relativement peu utilisé).
=> Vous pouvez alors envisager de stocker le texte dans une table secondaire, selon le schéma exemple suivant :

Règle de gestion :
Un biglotron peut avoir un commentaire et un commentaire appartient à un seul biglotron.

MCD :
Biglotron -0,1----avoir----(1,1)- Commentaire

Tables :
te_biglotron_big (big_id, big_reference, big_description...)
te_commentaire_com (com_id_biglotron, com_texte...)

Citation:

- Doit-on privilégier le stockage d'une variable booléenne ou une jointure pour regrouper des infos ?
(Par exemple, j'ai des produits qui peuvent être chimiques ou non et donc deux tables : une générale contenant tous les produits et une contenant uniquement les information spécifiques aux produits chimiques.
Comment savoir si un produit est chimiques ? Créer un attribut booléen dans la table produit ou faire une jointure sur l'identifiant du produit dans les deux tables et voir si on a une ligne correspondante ?)

Comme dit par escartefigue, faites un héritage.
Et créez une vue pour avoir toutes les informations des produits chimiques.

Règle de gestion :
Un produit peut être un produit chimique et un produit chimique est un produit.

MCD :
Produit_chimique -(1,1)----être----0,1- Produit

Tables :
te_produit_prd (prd_id, prd_reference, prd_nom...)
th_produit_chimique_pch (pch_id_produit, pch_formule...)

Vue :
Code:

1 2 3 4 5 CREATE VIEW v_produit_chimique AS SELECT p.prd_id, p.prd_reference, p.prd_nom, -- autres colonnes communes à tous les produits pc.formule -- autres colonnes spécifiques à tous les produits chimiques FROM th_produit_chimique_pch pc INNER JOIN te_produit_prd p ON p.prd_id = pc.pch_id_produit
Citation:

- Toutes les données d'un formulaire doivent-elle forcément être stockées dans la BDD ?
(A partir des données je créée en fait une fiche Word et certaines des informations ne sont pas utiles en dehors de cette fiche. Est-ce que c'est quand même mieux de les stocker dans la BDD ?)

Voir ma réponse plus haut à votre première question.
Prenez en compte la nécessité de reproduire ou non la fiche ultérieurement à sa création.
Vous pouvez aussi enregistrer le fichier Word sur le serveur et stocker dans la table le nom du fichier ou utiliser les possibilités DATAFILE ou FILESTREAM si votre SGBD en dispose (fichier stocké et complètement géré par le SGBDR).

Citation:

- Doit-on plutôt calculer la moyenne ou la somme de plusieurs autres variables à chaque affichage par un utilisateur ou les stocker dans la BDD si on veut les afficher maximum 10 fois par an ?

Faites le calcul à la demande. D'une manière générale et sauf cas particuliers, on ne stocke pas les informations calculées.

Citation:

- Doit-on créer un Id pour chaque table ou chercher plutôt une clé parmi les arguments existant ?

Pas pour chaque table. Voir plus haut les deux structures que j'ai données : mes tables te_commentaire_com et th_produit_chimique_pch n'ont pas d'identifiant propre ; leur identifiant est une clé étrangère référençant la table dont elles dépendent.

Les tables associatives auront aussi un identifiant qui sera composé des identifiants des tables participant à l'association. Voir mon billet de blog au sujet des tables associatives.

Citation:

- Y-a-t-il un avantage énorme à utiliser Oracle plutôt que MySQL?

Comme dit précédemment, Oracle est cher mais plus complet que MySQL.
Vous pouvez aussi considérer SQL Server qui propose une version gratuite et relativement peu limitée ou PostgreSQL qui est plus complet que MySQL tout en étant moins complet qu'Oracle ou SQL Server et qui est totalement gratuit. Notez que MySQL n'est pas réellement totalement gratuit selon l'utilisation qu'on en fait.

14/06/2018, 11h19
escartefigue

Citation:

Envoyé par CinePhil

Comme dit par escartefigue, faites un héritage.

Il faut rendre à César ce qui appartient à ... Aieeeuuuuu ;)

Citation:

Envoyé par CinePhil

Faites le calcul à la demande. D'une manière générale et sauf cas particuliers, on ne stocke pas les informations calculées.

Exemple d'exception : le montant TTC d'une facture, c'est la somme du HT plus la TVA, mais il faut le stocker, c'est un cas règlementaire
14/06/2018, 11h47
CinePhil

Citation:

Exemple d'exception : le montant TTC d'une facture, c'est la somme du HT plus la TVA, mais il faut le stocker, c'est un cas règlementaire

J'ai hésité à mentionner ce cas pare que les taux de TVA changent mais je me suis dit qu'avec une table des taux de TVA qui enregistre les dates de début et de fin de validité et une référence au taux pratiqué dans la table utilisant le taux, le calcul peut être fait a posteriori. Idem en enregistrant les remises éventuelles en taux ou en montant.

Pourquoi est-ce réglementaire ? Parce que la règle d'arrondi peut changer ?
15/06/2018, 10h44
escartefigue

Citation:

Envoyé par CinePhil

J'ai hésité à mentionner ce cas pare que les taux de TVA changent mais je me suis dit qu'avec une table des taux de TVA qui enregistre les dates de début et de fin de validité et une référence au taux pratiqué dans la table utilisant le taux, le calcul peut être fait a posteriori. Idem en enregistrant les remises éventuelles en taux ou en montant.

Pourquoi est-ce réglementaire ? Parce que la règle d'arrondi peut changer ?

Je ne sais pas, j'ai fait quelques recherches sans succès