Base de données "Golfiques"

Là j'ai plus le temps, mais j'y reviens ce soir...
a+
Gérald.

Bon,je pense que ce projet va restez à l'état de projet...
Quelle galère.
J'ai récolté plus de 4 gigas de données et je reste devant sans réussir à les articuler de façon simple et efficace.

Y'a pas à dire, c'est une tâche qui requiert des compétences solides...
Que je ne possède pas

ça va se terminer en feu de joie de données...

Euh .... c'est quoi l'idée ? Quelles données ?

si tu as quelques infos de ce que tu as comme données et comment les articuler, il n'y a pas de raison pour ne pas y arriver...question base de données, je n'en suis pas à ma première...alors si besoin d'aide n'hésites pas.

Gey a écrit:

Bon,je pense que ce projet va restez à l'état de projet...
Quelle galère.
J'ai récolté plus de 4 gigas de données et je reste devant sans réussir à les articuler de façon simple et efficace.

Y'a pas à dire, c'est une tâche qui requiert des compétences solides...
Que je ne possède pas

ça va se terminer en feu de joie de données...

Ben oui, c'est un métier

Bon je réessaye cette semaine d'appliquer des méthodes pour mon modèle de conception et mon modèle logique et si je n'obtiens pas un résultat satisfaisant, je sous-traite .

Déjà essayé Merise et "dérivé", y'a quelques notions que j'ai du mal à appréhender. Mais bon ça va "viendre"... je suis têtu .

Citation :

si tu as quelques infos de ce que tu as comme données et comment les
articuler, il n'y a pas de raison pour ne pas y arriver...question base
de données, je n'en suis pas à ma première...alors si besoin d'aide
n'hésites pas.

Je m'obstine encore quelques jours et je crie au secours après...

Citation :

Ben oui, c'est un métier

, tu veux dire que y'a des gens qui vivent de ça...

plus sérieusement, j'ai bien conscience que le développement de SGBD est un vrai boulot avec un vrai talent.

Citation :

Euh .... c'est quoi l'idée ? Quelles données ?

J'avais commencé à en parler dans la rubrique matos.
En fait le but est d'obtenir une base qui contient l'ensemble des matériels destinés à l'usage du golfeur.
Clubs, sacs, chariots, shafts, grips etc...
En fonction de la catégorie de matériel (Ci-dessus), les caractéristiques techniques seront bien différentes.
Je dois également intégrer pour aider l'utilisateur à faire une sélection de produit, des notes (dans les deux sens du terme) sur quelques critères qui seront aussi différents pour chaque catégorie de matériels. (ex: pour les "clubs" ont pourra y trouver "jouabilité" qui n'aura aucun interêt de figurer pour la catégorie "grips".

Dans ma tête c'est une usine à gaz...
Mais de se que j'ai compris des bouquins que j'ai lu sur la création de SGBD, plus y'a de tables, moins la base va être efficace (Temps de réponse, création des requêtes, saisie des données...).

Je dois donc trouver le bon compromis.
Ce qui me décourage "un peu" c'est que après tout ça, pour la mettre en ligne ca va être encore pire...

On se revoit dans 3 ans, pour jouer au golf, avant j'peux plus j'ai "info"...

J'vous tiens au jus de l'avancée des fondations
a+
Gérald.

La base de données c'est une chose, après faut s'occuper de toute l'interface utilisateur (quel langage de programmation ? quelle techno ?) et voir comment importer ou re-saisir facilement toutes les données que tu as déjà !

Donc t'es pas arrivé au bout ...

Citation :

Donc t'es pas arrivé au bout ...

Merci pour les encouragements...

Sérieusement, je pense que se sera, MySQL, .

Je ne voulais pas te décourager, je pense juste que c'est un projet très intéressant qui pourra te prendre beaucoup de temps!

Une solution pour avancer est de travailler en itérations successives. Tu commences par exemple par te concentrer sur une partie de la base, par exemple les clubs et les shafts, et de passer par toutes les étapes : modélisation et création de la base puis développement de la partie utilisateur. Une fois que c'est finit tu passes à la suite. Avec cette façon de procéder tu auras très rapidement un résultat et ça t'obligera à créer un modèle de donnés évolutif.

ok, mais le fait de ne pas prévoir dès le début toutes les tables ne va pas mettre en péril mon modèle au moment d'en rajouter une?

Non si elle est faire correctement dès le début, pas de soucis !

Citation :

correctement

à faire valider par un pro avant développement de la partie utilisateur donc...

C'est pas gagné cette affaire

Commence par faire le MCD, je pense qu'on sera plusieurs sur ce forum à pouvoir t'aider et te le corriger

Merki beaucoup,
a propos du MCD et MLD, Utiliser la méthode Merise est toujours d'actualité??

Oui c'est toujours d'actualité, en UML ou Merise pour la modélisation / description des données on décrit toujours la même chose :

- Des tables
- Les liaisons entre les tables (cardinalités ... 1 à 1, 1 à n, n à n, ...)
- Le type des données (Chaîne, entier, ...)
- Le type de colonne (index, unique, ...)

La différence entre les deux méthode est la façon de d'analyser ton logiciel et d'en tirer le MCD.

Bonjour,
ça c'est viable?

Click moi! click moi!

Sinon, je vois pas comment faire.

a+
Gérald.

Gey a écrit:

Bonjour,
ça c'est viable?

Click moi! click moi!

Sinon, je vois pas comment faire.

a+
Gérald.

pas vraiment, déjà, on ne fait pas une clé primaire avec un nom mais on crée un ID unique genre numéro incrémenté à chaque création. C'est cet ID qui se retrouvera dans les tables liées, ce qui fait que tu pourras changer le nom sans problème, sinon, bonjour la galère !!!.

Ensuite, tes liens ne sont pas bon à mon avis. "Catégorie", ne doit être lié qu'à "Produit", comme l'est "Fabricant" et c'est "Produit" tout seul qui est lié aux tables "Shaft" et "Clubs".
Si dans "Clubs" tu indiques quel est le shaft standard, tu devrais avoir un lien entre "Clubs" et "Shaft", pour justement pointer sur les infos du shaft standard.

voilà pour les premières critiques ;o)))

Bonjour,
Pour la clé primaire, je pensais que si le nom était unique, je pouvais le mettre en ID pour éviter de rajouter une donnée supplémentaire à savoir un Numéro auto qui ne correspond à rien en dehors du système?

Citation :

Ensuite, tes liens ne sont pas bon à mon avis.
"Catégorie", ne doit être lié qu'à "Produit", comme l'est "Fabricant"
et c'est "Produit" tout seul qui est lié aux tables "Shaft" et "Clubs".

Donc je supprime la table "Catégorie"?

Citation :

Si dans "Clubs" tu indiques quel est le shaft
standard, tu devrais avoir un lien entre "Clubs" et "Shaft", pour
justement pointer sur les infos du shaft standard.

Ok pour ça.

Comme ça?
http://www.hiboox.fr/go/images/divers/schema-sgbd-golf-1,ce78dfa55edbf422f732bd1d9b70d2b0.jpg.html

Merci pour l'aide, je me noie...

Produit est donc la table commune entre toutes les catégories de produit. Je pense qu'il faut y mettre un maximum de champs communs à tous les produits. Par exemple le prix, le poids, .... en fait tout ce que tu vas retrouver en commun. Mais si tu pars sur de la composition de produit (un club est composé d'un shaft et d'un grip) dans ce cas il vaut mieux laisser les données dans les tables Shaft et Club.

Tu peux laisser la table catégorie et la relier à produit.

Tu devrais essayer de nommer et d'indiquer les cardinalités sur les liens.

Vois aussi s'il n'y a pas d'autre champs à mettre dans des tables. Par exemple pour les matériaux tu peux en faire une table qui sera liée à shaft et club ?

En fait Je veux autant que possible mettre le moins de table.

Mais étant donné que les caractéristiques sont différentes en fonction de la catégorie de matériels, je pensais à 3 tables catégorielles:
Clubs
Shafts
Autres (Dans laquelle on trouvera sac, chariots, grips ...)

Dans cette dernière on trouvera des données génériques
Poids, couleurs, matière...

La grosse problématique c'est le lien entre les tables clubs et shafts.
En effet, on peut trouver des têtes de clubs (Donc sans shaft), des clubs à l'unité (Bois, driver, hybride, wedge, putter, fer à l'unité) ou des série de fers.

Sachant en plus que les shafts By le fabricants des têtes n'ont pas toujours les mêmes caractéristiques que le même modèle vendu par le fabricant de shaft...

Une vraie usine à gaz

Gey a écrit:

Bonjour,
Pour la clé primaire, je pensais que si le nom était unique, je pouvais le mettre en ID pour éviter de rajouter une donnée supplémentaire à savoir un Numéro auto qui ne correspond à rien en dehors du système?

c'est le principe des SGBD, l'ID ne doit correspondre à rien en dehors du système, d'abord cela permet de pouvoir facilement modifier une donnée et ensuite pour un problème de taille de base, un entier long prendra moins de place qu'une chaine de caractères qui doit être conséquente pour stocker un nom.

Gey a écrit:

Citation :

Ensuite, tes liens ne sont pas bon à mon avis.
"Catégorie", ne doit être lié qu'à "Produit", comme l'est "Fabricant"
et c'est "Produit" tout seul qui est lié aux tables "Shaft" et "Clubs".

Donc je supprime la table "Catégorie"?

Non, mais elle est lié à produit et pas à Shatf et club, donc dans ces dernières, il faut enlever le champ Catégorie_mat qui sera récupéré depuis "Produit"

Gey a écrit:

Citation :

Si dans "Clubs" tu indiques quel est le shaft
standard, tu devrais avoir un lien entre "Clubs" et "Shaft", pour
justement pointer sur les infos du shaft standard.

Ok pour ça.

Comme ça?
http://www.hiboox.fr/go/images/divers/schema-sgbd-golf-1,ce78dfa55edbf422f732bd1d9b70d2b0.jpg.html

Merci pour l'aide, je me noie...

je trouves que le projet est une mine à gaz.

c'est courant de vouloir centraliser l'information. néanmoins, le temps gérer cette masse et de l'entretenir doit consommer peu de temps et apporter un vrai plus.

et là je ne vois pas du tout l'intérêt.

qui souhaite avoir sous les yeux les millions de possibilités matérielles. Une personne isolé ne pourrais même pas digérer l'information d'un seul segment de la base.

Citation :

je trouves que le projet est une mine à gaz.

c'est courant de vouloir centraliser l'information. néanmoins, le temps gérer cette masse et de l'entretenir doit consommer peu de temps et apporter un vrai plus.

et là je ne vois pas du tout l'intérêt.

qui souhaite avoir sous les yeux les millions de possibilités matérielles. Une personne isolé ne pourrais même pas digérer l'information d'un seul segment de la base.

Merci!!!

J'y vois personnellement un moyen pour moi de me familiariser avec le monde des SGBD que je ne connaissais pas ou peu.

Me permettre également de transposer cette base sur le web et ainsi me faire manipuler un ou des langages informatiques.

Il faut savoir que l'idée m'ai venue au moment ou j'ai entreprit de l'auto-apprentissage de la maintenance et administration des réseaux et systèmes.

Mais ça peut te sembler stupide ou sans intérêt de vouloir préparer ma reconversion professionnelle en utilisant ma nouvelle passion: le Golf.

J'ai précisé sur mon premier post que vos avis seraient les bienvenus:

https://le-golf.forumactif.com/le-materiel-f39/base-de-donnees-t9372.htm

Je note donc que ce travail (Utile pour moi) ne sera pas forcement d'une grande utilité pour toi.


As-tu une autre idée sur une telle base de données?
Si oui, que voudrais-tu y retrouver?
Quelles seraient tes attentes sur les possibilités d'interroger cette base?

Je suis ouvert à TOUTES les critiques.

Merci.
a+
Gérald.

tout comme phil, placer un Id comme clef primaire (plus rapide pour une jointure que sur un alpha, et moins gourmand en taille).

je ne suis pas assez calé en matos mais tu peux bien avoir un fabricant de shaft différent d'un fabricant de club, non?

bon je regarderai demain à tête reposé tout çà...

désole si ce n'étais pas le topic pour le donner, c'est juste un avis.

en aucun cas je souhaite te décourager. ton idée d'expérimentation derrière est ingénieuse. une belle utilité donc.

mais si tu sais faire des BDD, tu sais faire des états et des formulaires pour la saisie.

donc par exemple sur 2010 le forum pourrait saisir des données de jeu, et la base pourrais présenter des statistiques, non ?