Bonjour,
 
Je suis novice au SGBD et j'aimerais connaitre les possibilités de ces systèmes.
 
J'aimerais mettre en place un SGBD capable de récupérer des informations provenant d'automates (essentiellement des valeurs numériques) toutes les minutes et raffraichir toutes les minutes des programmes associés au SGBD: affichage des valeurs, calculs simples sur ces valeurs et aussi des comparaisons (par exemple >0) retournant une valeur booléenne VRAI/FAUX qui engendrerais une demande d'explication à l'utilisateur du programme (remplissage d'un champ description par l'utilisateur).
 
Est-il possible d'interroger le SGBD aussi rapidement après l'enregistrement des données(assez importantes en nombre)? Y a t-il un SGBD mieux adapté que les autres pour ce genre de programmation?
 
Je vous remercie par avance

J'ai l'impression que tu mélanges un peu SGBD et applicatif.
Dans l'absolu, un SGBD ne va que stocker des données, absolument rien d'autre. A quelqu'un, ensuite, d'écrire un applicatif (un programme quoi) qui va récupérer les infos et faire ce dont tu as besoin.
 
Le SGBD, ici, "ne va servir qu'à" stocker ces infos.

et accessoirement, oui, tu peux inserrer des milliards de lignes et les interroger la milliseconde suivante, le tout de façon asynchrone.
 
le SGBD gère lui-même les problèmes de locks et transactions (on ne peut pas lire des informations qui ne sont pas encore commitée, ou une requête est mise en attente tant qu'une données est bloquée par un process)
 
Niveau choix de la base, là il n'y a pas assez d'informations :
- quel est ton environnement ? (os, réseau d'entreprise, etc.)
- quel(s) langage(s) comptes-tu utiliser pour faire l'applicatif qui va interroger/alimenter ces données ?
- quel est le volume des données ? et des mises à jours?

Sans oublier une question importante :
- quel est ton budget pour les éventuelles licences ?

Merci pour vos réponses. En effet j'avais quelques difficultés à différencier SGBD et applicatifs.
 
Sinon à propos de l'environnement, on travaille sous windows 2000 avec des PC et des terminaux reliés en ethernet au réseau, on dispose d'oracle9i je ne connais pas la licence mais peut être qu'un autre SGBD serait meilleur.
Au niveau de l'applicatif je pensais au Java étant donné que je cherche un applicatif très visuel, intuitif, simple d'utilisation, avec affichage de courbes et que Java offre pas mal de possibilités aujourd'hui mais cela reste à définir.
Au niveau du volume, ce serait une centaine de valeurs numériques à récupérer toutes les minutes tous les jours et de l'ajout de texte commentaire ou choix multiples par l'utilisateur, ca ne devrait pas avoir un volume important.
 
Et niveau budget, ça dépendra du dossier d'investissement donc du meilleur au moins pire pour les licences.  

Ben si vous avez déjà Oracle9i, avec j'imagine la pléthorre de DBA nécessaires, ce serait dommage de s'orienter vers une autre solution. Mais je ne connais pas ton infrastructure non plus.
 
Niveau volume, c'est effectivement négligeable. Et pour le GUI, je laisse d'autres juger, je ne suis pas bien placer pour cela.

si vous avez déjà Oracle, ça sert à rien d'en prendre un autre. c'est pas la dernière version, mais à la limite ça changera certainement rien.
 
par contre, c'est clairement un des plus chauds à configurer en tant qu'admin. mais c'est aussi un des meilleurs produits dui marcher, donc ça sert à rien de s'en passer.
 
pour le langage, même si j'aime pas Java, ça me semble effectivement un bon choix. tu n'auras pas de problème de connexion avec Oracle, il y a tout ce qu'il faut.
 
niveau volume, Ca m'a l'air plus qu'à l'aise.
 
60 * 24 * 365 = 525 600
 
Donc si je me suis pas planté, il faut 2 ans pour avoir 1 million de lignes. ce qui veut dire que vous en aurez 10 millions dans 20 ans. à ce rythme, vous risquez plus la panne matérielle de vieillesse que la saturation du serveur y'a même pas besoin de prévoir de purge des données.

Heureusement que c'est pas ce qui se passe hein ... ah si on me dit dans l'oreillette que les SGBD de merde pas ACID ne fonctionne pas non plus en mode snapshots.
Vive Postgresql. (ok oracle aussi).

+1. Si l'entreprise à la licence, il faut l'utiliser. Oracle est un SGBD ultra puissant avec lequel on peut tout faire

Par contre, comme tu le soulignes tu es novice en la matière. Alors demande à l'entreprise de te prêter un manuel d'utilisation d'Oracle. Car ce SGBD demande quand même de bonnes connaissances théoriques pour pouvoir utiliser le langage SQL qui lui est approprié.

oui enfin ceci dit, même si oracle a certaines spécificités (comme tous les SGBD) sa syntaxe SQL n'est pas particulièrement différente des autres. ça reste quand même standard pour la plupart des traîtements. c'est quand on tape dans les fonctionalités avancées que ça ne respecte plus rien (connect by, etc.)
 
par contre, niveau administration, c'est clairement la merde comparé à de nombreux sgbd qui offrent des interfaces claires. (20 lignes de grant pour réussir à faire un select dans une table c'est un peu chiant )
d'où l'importance d'avoir en interne une personne qui sait administrer la base.

merci pour toutes vos réponses. Moi je m'occupe de l'écriture du cctp pour la mise en place du sgbd, et il y aura personne pour administrer réellement cette base (il y aura un contrat de maintenance c'est sûr mais je ne sais pas quelle sera la rapidité d'intervention) donc on va voir pour oracle.  
Sinon vous pensez quoi d'access pour recevoir cette quantité d'informations par le réseau (déjà ça ça demande de la prog) avec quatre applications différentes associées (sur 4 postes différents) et pouvant parfois accèder à une même table?
 
Encore merci, maintenant je vais essayer DBdesigner ^^

ben faut pas non plus avoir peur.
 
oracle, une fois que c'est en place, si l'admin a correctement fait son taff, t'as pour ainsi dire jamais de maintenance à faire.
 
la partie chiante, c'est entre le moment où le serveur est installé et le moment où tu peux utiliser la base dans ton programme.
 
ensuite, les tâches courantes sont automatisables, et les rares cas qui nécessitent urgence se voient venir à l'avance. (table space qui explose par exemple, l'admin a le devoir d'activer des alertes lorsque qu'il est proche de sa taille limite par exemple, et au setup on prévoit des valeurs suffisament grandes pour ne jamais en avoir besoin, d'autant plus quand on voit le prix des disques actuellement )

je pense que tu vas avoir des gros soucis avec Access rapidement. Voila pourquoi :
tu dis Au niveau du volume, ce serait une centaine de valeurs numériques à récupérer toutes les minutes tous les jours

on va dire 100 valeurs par minute. en 24h : 24*100*60 = 144 000.
Access, jusqu'à la version 2003, et à mon avis la version 2007 n'a pas changé, tu peux avoir un peu moins de 66 000 enregistrements par table!
Autrement dis... l'application plantera en moins de 12h
Donc oublie Access, en plus il gère très mal le réseau, il ressemble à un SGBD mais il n'en est pas un.

Vouloir utiliser access alors qu'on a oracle à disposition.
 
J'suis pas fan d'oracle. Pas du tout même, maintenance trop lourde et autres chianteries des familles. Mais autant oracle n'aura pas la moindre microgoutte de sueur à gérer le volume que tu proposes ici, autant access, j'ai beaucoup plus de doute.

slr56 > Pour être plus exact, à partir d'une valeur qui varie d'une version à une autre d'Access, Microsoft ne garantie pas la qualité du fonctionnement d'Access : lenteur, plantages, données erronnées. Mais dans les faits, Access n'a aucun problème pour travailler avec des tables de 1 million de lignes.
 
Cependant, l'ensemble des limitations (multi-accès très limité, etc.) fait que pour une application non mono-poste, Access est à oublier illico-presto.

Je suis globalement d'accord avec vous : Access, à éviter, surtout quand on a Oracle à disposition.
Mais il ne faut pas non plus tomber dans la désinformation ! Une base Access correctement développée et maintenue peut gérer plusieurs millions d'enregistrement !
J'ai bossé pour une boite qui avait développé et qui maintenait une base access 97 qui contenait une table d'1 millions de lignes. Et ça marchait !
 
Bon, je ne dis pas que c'est une solution valable, mais c'est possible !

d'où la précision que j'ai apporté
 
mais le côté mono-poste d'access fait que la mise à jour depuis 4 sources (et certainement la consultation depuis plusieurs postes) rend la solution access assez peu viable, et source de gros problèmes potentiels.

Cross post en fait