Slt
Je dois developper une outil de gestion d'inventaire avec consultation et maj dynamique, pour une administration ou je fais mon stage ...
 
Il devrait y avoir moins de 10 tables dont 2 contenant pas mal d'enregistrements (mais pas des million non pu)
 
J'ai deja levé les regles de gestion, attributs , mcd et  mpd mais j'hesite avec quels outils le construire:
 
- easyphp (oracle, php, mysql) : simple et gratuit
- access + asp + iis : access bof bof pr les requetes sql je pense
- sinon ya d'autre choix :
  - php + iis +access (contre nature)
  - oracle + php/asp...
 
Sachant que je me servirai de dream mx ensuite...
 
Bref lequel est le plus simple niveau maintenance et utilisation.    

Si ton truc n'est pas destiné a beaucoup évoluer, moi je partirais sur access qui permet quand meme de faire une bonne appli (tu peux aussi toucher du VB avec access si t'es limité) sans trop se prendre la tete. Vu que t'as que 10 tables la relationnelle ne devrait pas te poser de pb. je pense pas que tu sois bloqué avec sql access pour ton appli, access c'est pas non plus aussi pourri qu'on le dit.
 
Je connais pas trop mysql mais d'apres ce que j'ai pu comprendre, il encaisse les bases relationnelle qu'en rusant un peu et n'est pas trop prévu pour ca a la base (j'en suis pas sur, a verifier). Pas de triggers non plus. Maintenant sur le net, yen a qui ont l'air de bien s'acharner avec mysql et de faire des trucs vraiment bien (faudrait regarder comment ca tourne, usine a gaz ?)
 
Sinon moi je suis sur oracle, php en 3 tiers en ce moment meme. Bon ben oracle on le sait c'est la machine donc qui peut le plus peut le moins mais est ce bien la peine ?
 
Donc reflechis a ce que ton projet nécessite (prevois les requettes tordus ou ce genre de truc) et regarde les fonctionnalités de chaque configuration. Fais aussi attention a la mise en place : si tu peux etre client un server oracle deja en place ou si tu dois en plus en faire un (c'est pas pareil). Pense a ce genre de trucs et tu devrais bien t'orienter.

Ben y a déjà ce forum  

Pr oracle faudrait faire un server. C cho ?
Sinon mysql ne gerait pas les clef etrangeres (controle a faire a l'insertion) mais peut etre que ca a ete corrigé depuis.
 
Sinon ca serait 100% gere par intranet donc pas de vb pr les formulaires et autres . Sinon entre php et asp (classique) je pense que c kif kif...
 
Bon ben ca a l'air de s'orienter access... (une question, c'est possible avec access de faire une clef unique composée de l'aggrégation de plusieus champs ?)

Moi je ne pense pas que Access soit suffisant. Moi aussi je suis en stage, et quand je suis arrivé, on m'a chargé d'accelerer la table existante (Access), peu importe les moyens utilisés. Aprés m'etre renseigné un peu partout, je me suis vite rendu compte que Access était trés limité. Si une de tes tables contient plus de 20000 enregistrements, abandonne Access, sinon a voir.  
Je te conseillerais Mysql, c'est ce que j'utilise.

Top posts synchro !!    

@hfrfc  
 
Wesh wesh!!!!

 
 
 
ca gere les clefs etrangeres mysql now ?

 
nonon si je me rapelle d'un truc en mysql c'est l'integrité referentielle a été oubliée jusqu'à maintenant...
 
Quant à "faire un server oracle", ben faut etre un peu logique. Quand je te demande de reflechir a la mise en place dans l etablissement ou tu te trouves, les questions à se poser :
 
- De quels moyens hardware et software je dispose ?
- De combien de moyen financiers je dispose pour mettre en place du hard ou du soft
- De combien de temps je dispose  
- Quelle quantité de savoir nouveau je peux emmagasiner et mettre en oeuvre dans mon temps imparti
 
Tu comprends bien que si la ou tu bosses ils tournent pas sur oracle, deja faut capter que faut acheter la boite ($$$). Ensuite faut administrer ton server (c'est ptet un peu plus chiant qu'un setup microsoft office). Faut lui balancer des clients si ton server intranet web n'est pas confondu avec ton server apache.
 
Si on te dit on te file que dalle, t'as un P3-500 la-bas au fond de la grange a droite, un prise rj45 de la flotte et du pain. Tu comprends bien que tu vas devoir tourner avec mysql...
 
Par contre si on te dit que tout le systeme d'application de ton etablissement repose sur un server oracle et qu'on peut t'allouer un login, ton espace pour faire 10 tables et un client Oracle pour ton server web... ben c'est pas pareil tu vas pas cracher dessus.
 
un peu de bon sens les gars

@hfrfc  
 
ouai foreign key existe!

alors j'ai rien dit

ça depend de ta version, mais si tu utilise la version 3.23.56 et au dela (4.1) elles y sont!
C'est pour ça, je lui conseil mysql.

masure : ok chef   Bon je laisse tomber oracle, jai pas les connaissance pr le mettre en place ni le matos.
 
toutoun88 : a serieux c'est integré now ! C bien ca ! Tu les specifie avec phpmyadmin    ou tu doit integrer a la creation des tables les contraintes genre : foreign key(nom) reference titi(nom)    
 

Le jour ou vous reflechirais avant de poster (1) ou encore de reply (2) on sera sauvé. Je suis desolé mais avec les infos qu'il fournit on peut pas trouver la meilleure solution.
 
Si lui meme n'a pas les infos, qu'il aille se renseigner.
 
Si il a les infos et qu'il n'a pas reflechis aux consequences sur la mise en place de son projet et bien qu'il en tienne compte.
 
Alors les replyers : on arrete de dire ceci ou cela sans savoir de quoi il s'agit car c'est du 0/20

 
Amen ! une decision murement reflechie, j'aime quand ca se passe comme ça

@hfrfc  
 
Personnelement, je les specifies a la creation de la table car je n'utilise pas phpmyadmin, mais WinMySQLAdmin :
 
FOREIGN KEY (id_truc) REFERENCES truc (id_truc)
 
Mais j'ai entendu dire qu'on pouvait les specifier avec phpmyadmin.
Bonne chance!

merci de votre aide, tous les 2

 
No problem
 
good luck aussi  

Question simple :
 
La base doit-elle être multi-utilisateur ?
 
- Oui : Oublie Access, oriente-toi vers MySQL, Oracle ou MSSQL Server (bien moins cher que Oracle, mais tout aussi surdimensionné pour ton truc)
- Non : Access sera très certainement le meilleur choix, sans forcément passer par une interface web.
 
Sinon, juste un petit truc à propos des perfs d'Access.
J'ai trouvé ça dans MSDN Library alors que je cherchais des infos sur Access. Ca me semble pas mal, et si tu suis tout bien à la lettre, les performances pourrait être très largement meilleures que de base.
 
http://www.manga-torii.com/files/access.htm

Ouais en fait le service ne sait pas trop.
 
Yaura sans doute 2-3 personnes qui pourront rentrer des informations tandis que d'autres ne pourront que la consulter.
 
Comme les personnes qui me demandent ca n'ont pas reflechie a ce qu'elles voulaient c'est dur de repondre mais je pense qu'il peut y avoir ++ utils en meme tps (mais pas 30 en meme temps par exemple)

 
Avant de te lancer (je sais que c'est rengaine), défini bien le cahier des charges en fonctions des besoins. Tu perds un peu de temps mais 1) tu sauras ce qu'on veut reellement 2) ca te baignera dans le truc et tu n'en travailleras que mieux

Le pb c que tout le monde est en vacances la.. De plus vu que c une administration ils en ont un peu rien a foutre. Ca leur est passé par la tete ce projet mais ils ne se sont pas concerté pr dire ce qu'ils veulent exactement. Dans un premier temps jai deja passé une semaine a reformuler le fonctionnement de l'inventaire. Puis jai fait l'analyse ... Que faire de + ?
 
Niveau matos ben c limité sinon...
Donc bon en tenant compte de ca, faut un truc simple qui tourne correctment.

Prend le 1er responsable susceptible d'etre concerné par ton travail (responsable service info, responsable du service pour le quel tu developpe, ...) et tu lui dis que tu as besoin de connaitre le reel besoin donc d'infos precises alors :
 
1) soit je fais avec ce que je comprend du fonctionnement du service et vous viendrez pas pleurer si ça correspond pas au besoin totalement
 
2) soit vous prenez la peine de répondre à mes questions pour une bonne étude et on a quelquechose qui colle parfaitement.
 
Et tu lui demande de choisir. Faut qu'il comprenne bien que c'est soit l'un soit l'autre et que ça ne depend pas de toi.
 
Ne te laisse pas embarquer dans le "je m'en foutisme" de la boite

Ouais mais bon j'ai peur que ca soit mal pris. Qd on est stagiaire c'est un peu comme si tu etais transparent
 
Enfin bon jai fait validé le mcd en 5 minutes sur un coin de table par un responsable (non informaticien) ...  On a d'ailleurs supprimé des tables et relations car il trouvait qu'il y aurait trop de mises  a jour des informations a faire ^^ . Qu'est ce que tu veux repondre a ca ?? Enfin c son probleme...
 
Enfin bon je vais po me plaindre ya sans doute pire...
 
Actuellement je suis en train de chercher la solution la plus adapté pr construire le truc , je vais tester access /asp et easyphp...

T'inquiète je suis en stage aussi là , j'ai mon server apache, php qui tourne sur la machine avec laquelle je poste sur notre joli forum. Quand je te parle pas je fais le systeme de sessions de l'appli intranet qui s'appuie sur oracle.
 
Allez courage les stagiaireuh  

je renchéris avec les autres: avant de définir tes besoins techniques, cuisine tes futurs utilisateurs pour savoir ce qu'ils veulent le plus précisément possible, combien ils seront sur ton appli etc...   En fonction de tout ça, tu pourras faire un meilleur choix sur les technos que tu vas employer.  Toujours procéder dans l'ordre: étudier l'existant, étudier et inventorier les besoins fonctionnels et les regrouper selon la logique désirée, puis faire l'analyse technique.  C'est comme ça qu'on arrive à faire des choses robustes qui vont bien.
 
En ce qui concerne MySQL, je vais le dire encore une fois
 
MySQL 3.23 gère les foreign keys MAIS uniquement après avoir activé le module InnoDB, et uniquement sur les tables de type InnoDB (par défaut on travaille en MyISAM).  C'est une différence entre MySQL et les autres SGBD, tu peux choisir le type de table.
 
Mais vu que pas mal d'applications webs dont pas mal de forums, dont celui (ouf) utilisent MySQL sans les foreign keys, on peut se poser la question: est-ce vraiment nécessaire?  Si la DB est beaucoup plus souvent interrogée que mise à jour, il se peut que non.  Ca dépend aussi du modèle de données.  Est-il complexe?  Si non, un serveur MySQL avec les tables par défaut (MyISAM) suffira certainement.
 
Il y a un truc à savoir à propos des foreign keys en MySQL.  Dans tous les cas, ça a l'air de passer, mais en fait, si l'InnoDB n'est pas activé, MySQL se contentera d'ignorer les clauses définissant les foreign keys.
 
Voilà, bonne chance pour ton boulot et n'hésite pas à repasser si tu as encore des questions

ouais je viens d'aller voir le site mysql et je viens de lire les restricions sur les foreign keys...
 
Mais quelles sont les diffs entre InnoDB et  MyISAM ?
D'apres ce que j'ai lu innodb a l'air plus solide et plus rapide sur les larges tables mais ca a l'air plus chiant a configurer
 
http://www.mysql.com/documentation [...] noDB_start
 
Sinon sans clefs etrangeres pour les insertions ou les updates on est donc obliger de tout verifier sinon ca va faire des incoherences... C'est quand meme bcp plus contraignant   !

 
Donc je m'etais pas totalement planté pour l'integrité referentielle et MySQL. Maintenant vérifier l'integrité a la main c'est pas la mort si tu encapsule en PHP tout tes acces (consultation ou maj) a ta base de donnees. Tu vois ce que je veux dire?

non dsl...
Je suis trop habitué au clef etrangeres

 
Ah ben quand on a pas de sous   on fait avec ce qui est gratuit que veux tu
 
Viens chez moi on va taquiner le oracle/apache/php, tu vas voir c'est fun avec mes copines les foreign keys  
 
courage c'est pas la mort de se gérer les clés etrangere en encapsulant

Vi, et tu divise les perfs par deux, sans parler des problèmes de transactions.
 
Je sais pas sur combien de niveau d'encapsulage de transactions monte MySQL, mais si on doit se palucher toutes les transactions implicites à la main, ben on risque rapidement d'atteindre le quota...

 
Heu, avec des clès étrangère, çà te dispense pas de vérifier.
T'es quand même obligé de vérifier si le SGBD ne t'envoie pas sur les roses avec une MAJ interdite !
 
Alors, au lieu de tester les messages d'erreur, ben tu fais tes vérifs toi-même !
 
Et c'est bien plus propre à mon avis ! ( Oui, c'est MON avis, que j'ai donné plusieurs fois içi   )
 
Un exemple que je trouve significatif :
 
Avec le seul test d'intégrité :
Tu propose une liste de trucs.
L'utilisateur peut choisir ceux qu'il veut supprimer.
Tu demande confirmation ( pour une suppression, c'est ce qu'on fait en général )
Ensuite tu lance le(s) delete(s).
Et là, PAN, le SGBD te dit que s'est pas possible, et l'utilisateur te maudit !
 
Avec vérif avant :
Tu propose une liste de trucs. Mais comme t'est gentil, tu ne propose pas la case supression pour ceux qui ne peuvent pas l'être.
Le reste est identique, sauf qu'en cas d'impossibilité de suppression ( à vérifier, mais t'as déja le code pour çà ! ) à cause d'une MAJ par un autre utilisateur, ben t'as une excuse pour expliquer que t'as proposé un truc qui est devenu impossible !
 
A toi de voir.

je plussoie, après avoir tâté les deux, je préfère faire les vérifs moi même, le programme n'en sera que plus secure après (surtout sur le web où on peut trafiquer les paramètres comme des fous).

Mara's dad >
 
1) En SQL, quand c'est un vrai SGDB Relationnel, il y a "CASCADE CONSTRAINTS" qui te permet de supprimer en cascade toutes les données liées à celles que tu supprimes.
 
2) Ton système il est bien beau, mais si pendant que ton utilisateur choisi parmis la liste des données à supprimer, qu'il peut supprimer, un autre utilisateur écrit une info qui va faire en sorte qu'une des entrées de ta liste ne ^peut plus être supprimable, ben tu vas tout de même supprimer la ligne, mettant en péril l'intégrité de tes données.
 
3) Les transactions (implicites ou non) servent justement à permettre de faire un premier delete sans check des contraintes, et en cas d'erreur, revenir à l'état original, et afficher une popup demandant si on veut virer les données dépendantes, et on relance cette fois la requête avec "cascade constraints"

 
qd tu parles d'encapsulation, tu peux preciser svp  

 
Bonjour MagicBuzz, j'attendais ta réaction
 
1) Cascade constaints : Heu franchement tu l'as souvent utilisé ? Si oui, je ne pense pas que ce soit le cas général.
2) Non, relis ce que j'ai écrit : La vérification est faite une 2éme fois, juste avant la supression.
3) OK, voir 1).
 
Je ne remet pas en cause les SGBD relationnels, les transactions c'est très bien, mais surtout en batch, ou dans quand tu lance un process de validation des données de plusieurs écrans.
 
Tout ce que je dis, c'est que çà ne dispense pas d'écrire le code de vérification de ce qui doit être fait ou pas. Et que donc, si le SGBD choisi n'est pas relationnel, c'est pas çà qui va changer grand chose au nombre de ligne de code pour un simple écran de saisi tout con.
 
Enfin, s'il à les moyens et le matos, ben, même pour une petite appli, Oracle c'est très bien aussi.
Mais si c'est pour choisir entre Access et MySql, ben je choisi MySql, d'autant qu'Acces n'est pas gratuit !
 
A+

 
 
ben tu ecris autant de fonction php que d'operations que tu auras a faire avec ta BD. Dans ces fonctions, tu fais l'interface php-BD en gérant les erreurs dans ta fonction php.  
 
Exemple : si ta fonction ajoute un client dont le nom ne doit pas depasser 64caracteres, tu traite le probleme dans ta fonction php au lieu de balancer ca a ton SGBD qui va te balancer des supers erreurs. En gros ca donne ca :
 

 
 
un truc dans le genre

oki
 
Bon j'ai parlé avec le responsable comme vous me l'avez conseillé  et bon c vite vu.
C'est access + asp, obligé... alors qu'il m'avait dit que jt plutot libre au debut du stage.
Donc bon ben on va faire avec
 
Access gere les clefs etrangeres si je me souviens bien...

 
oui Et contrairement à MySQL, Access gère les requetes imbriquées.

mouais, t'as du lui faire peur à parler de MySQL/PHP
 
si ça se trouve il sait même pas ce que c'est