gestion d"inventaire en PHP: suggestions?

[po134]

Bonjour,

outils a utiliser:
PHP
Mysql (ou autre ?)
EZPDO ?

J'ai été mandaté pour la création d'un inventiare pour une entreprise ( voir le topic

Vous devez être connecté pour voir les liens.

pour le modèle qui m'était proposé de réalisé). De mon côté j'en ai fait un autre vite fait:

Vous devez être connecté pour voir les images.

Vous devez être connecté pour voir les liens.

Et l'analyste (C'est un titre hen ... il l'est pas de formation) aimerait bien l'approche objet comme moi d'ailleurs (On a fait que ça ou presque durant ma technique, donc c'est en quelque sorte mon élément). Ensuite je me suis dit, bon voila un modèle de classe, mais mysql n'est pas dutout orienté objet, donc ca compliquerait la prog de monter un modele avec des table comme mes classes. C'est la que j'ai regardé les ORM disponibles pour PHP et j'ai trouvé EZPDO (Easy PDO)

Vous devez être connecté pour voir les liens.

et je suis toujours en phase de lecture/test pour savoir s'il serait convenable de l'utiliser dans un projet qui est d'ailleurs porté a évalué après mon départ.

J'aimerais avoir vos commentaires sur les options s'offrant a moi.
EZPDO me semble bien, mais certaines limitations au niveau de certines fonctionnalités me semble pouvoir resurgir et poser probleme dans le futur. Il offre quand même des méthodes très utiles comme find(object) tout en gérant les agrégation 1:N et N:M directement a partir des class objet.

Merci d'avance
- Le novice

 

[zeb]

(Pourquoi répéter l'ID ?)

 

[po134]

Ah car je suis habitué a avoir un id unique a chaque table ... mais t'as parfaitement raison dans ce cas c'est inutile puisque tout se compose de mon matériel. héhé

En fait j'avais fait ça pou réviter de mettre une clé alternative avec la clé utilisé dans notre entreprise sur certains matériel (écran/pc) et pas sur les autres, mais ca évitera le gaspillage en mettant cette clé sec dans matériel et enlevé les id partout. ^_^

 

[zeb]

Rhoo, on n'en est pas encore au niveau des tables là !

Ben ton modèle est pas mal. On voit tout de suite qu'il n'est pas utile de faire des tables pour scanner, palm et périphérique.

Après, à toi de voir comment tu dénormalises ta base.

 

[po134]

bah en fait j'ai tout simplement tout mis ce qu'on avait en inventaire comme table tout bêtement (Je vois tjrs le côté "ca pourrait nous servir plus tard" meme si cest inutile hehe)

De plus, faut bien que je signifit leur type quelque part (pour les recherche par exemple) donc voici:

Vous devez être connecté pour voir les images.

Vous devez être connecté pour voir les liens.

Seul hic avec se modèle: j'ai deja mon objet Écran, donc je me fou du type pour ce genre d'objet, mais si un jour j'ai un palm, il y aura PALM dans TypeMateriel... sauf ca me fait comme cette endroit a regarder comme type d'objet ET la table en agrégation ce qui est pas génial je trouve.

 

[zeb]

C'est le problème de la dénormalisation de l'objet vers le relationnel. Soit on laisse tomber l'analyse objet (Pour un petit projet, ce n'est pas grave, mais tant qu'à faire, autant prendre de bonne habitude et rester à l'objet), soit on accepte de dénormaliser sa base de données, soit on utilise un gestionnaire de base de données objet. Hein ? ça n'existe pas ? Ah bah oui.

 

[po134]

Au début l'analyste voulait faire ça relationel, mais j'ai décidé de faire de l'objet. Donc, j'ai choisi d'utiliser EZPDO (Easy PDO) qui fait en sorte qu'on travail avec des objets, même si MySQL est relationel.

Voila a quoi ca ressemble maintenant: (Meme si certains objets sont vides )

Vous devez être connecté pour voir les images.

Vous devez être connecté pour voir les liens.

 

[zeb]

sauf ca me fait comme cette endroit a regarder comme type d'objet ET la table en agrégation ce qui est pas génial je trouve.

Dans une base en troisième forme normale, ce genre de problème n'existe pas. L'accepter, c'est dénormaliser sa base. C'est typiquement le dilemne des solutions objets sur base relationnelles :

Soit tu remontes tous tes champs dans la table Matériel, et tu auras des champs à NULL en fonction du type de matériel, soit tu descends tous les champs de la classe mère dans les tables filles et tu auras plusieurs fois ces champs, soit tu conserves la table Matériel et les tables filles avec des relations 1-1 et il te faudras regarder dans plusieurs tables

Pourquoi un agrégat entre Matériel et TypeMériel. A mon sens, il ne s'agit que d'une relation toute simple entre une entité et le référentiel.

 

[boub popsyteam]

Et sinon, stocker du xml decrivant "l'objet" dans un champ ?

 

[po134]

zeb> T'as raison, c'était pas des agrégations, car je ne créais pas les types en même tant que le matériel lui meme (meme chose pour ordinateur/modele)

Au fait, le travail et presque terminé, il me restera encore la partie logiciel a développer et mes tests unitaires a réaliser, mais le gros est la.

Au fait EZPDO a grandement simplifier le travail me permettant de passer directement de mon diagramme de class a mes class réelle en oubliant les tables mysql.

(la partie logiciel/licence est temporaire, il manque pleins de choses)

Vous devez être connecté pour voir les images.