Bonjours.
j'ai un petit projet assez simple que j'ai en tête.
Il sagit de voir l'activité d'une SGBD en temps réelle. Je voudrais afficher toute les tables d'une sgbd et lorsque celui-ci est vient d'etre accedé en lecture ou écriture elle puisse clignoter ou autre peut importe mais qu'elle language adapté ou la maniere car je voudrais pas que cela puisse solicité en plus sur le moteur de la bdd.
merci.

A la maigre étendue de mes connaissances dans le domaine, il est impossible de programmer un sgbd pour envoyer des alertes
en revanche, ca sera au programme "alerte" de scruter à intervalles réguliers les changements
niveau vitesse, je sais pas ce qui est le + rapide, comme ça à brule-pourpoint je dirais c++, mais à mon avis, comme tu ne peux pas te permettre de scruter toutes les 1000/ièmes de secondes (le proc va devenir fou), faut faire un rafraichissement toutes les 2-3 secondes, donc n'importe quel langage peut faire l'affaire
 
est-ce que qqun peut confirmer pour les sgbd "intelligents" ? sql server peut-être ? Arjuna, grande prêtresse, qu'as-tu à nous dire à ce sujet ?

ben ya les triggers, c'est pas mal comme intelligence de SGBD
 
Par contre pour lier des opérations lancées par les triggers à une appli extérieure, faut voir les capacités programmatiques d'un Oracle ou d'un SQL-Server
 
Ou bien alors tu fais ça à la mano comme le suggère Trevor (c'est à mon avis l'approche la plus saine, la plus logique et la plus simple) et tu "poll" ton SGBD depuis ton appli externe (avec un délai donné, genre toutes les 1s ou toutes les 0.5s), et tu récupères soit les métadonnées de tes différentes tables (les SGBD doivent sûrement stocker les états, derniers accès, dernières modifs, ...) soit le contenu d'une table gérée par tes triggers de lecture/écriture
 
Ah, et évite de rêver, Free Food ça ne dure qu'un temps, ça va bouffer des ressources à ton SGBD c'est inévitable.

Je pensais justement à un trigger qui puisse envoyer un signal celui à qui veut l'entendre. un trigger pour un select,update,insert,delete avec l'envoy si possible d'informations. J'ai pensé dans ce sens plutot qu'un programme qui interroge la bdd car c'est trop de ressources d'occupées.
Je pensais le faire en C# ou VB.net  
Pour mysql j'ai pensé au systeme de fichier, que le programme puisse écouté si le fichier à été modifié ou lu. Il me semble que les objets COM peuvent faire cela.  
Autre solution pour les différents SQGB, c'est d'écrire via un trigger ou un programme qui coquine avec la base, de logé toute les requêtes qui sont passées et de lire simplement le fichier en lecture temps comme une timeline. l'Inconvenient c'est pas en temps réelle mais soulage la BDD (un peut).

Nan mais t'as fait des tests de charge sur un polling simple au moins
 
C'est pas un select à la con sur une table contenant 3 enregistrements qui va tomber une base hein

Je sais pas si c'est pareil avec des bases comme oracle, mais avec mysql, t'as "show processlist" qui te retourne la liste des conections active avec leur état actuel et depuis combien de temps ils ont lancé la derniére commande.
Si la derniére requette demandé par une conection donnée est terminé alors il n'est pas possible de savoirr si c'était un select ou un update mais tu pouras au moins savoir s'il c'est passé quelque chôse pendant l'intervale d'attente.

Ce qu'il veut c'est plutôt la dernière mise à jour des tables

Pour mysql comme c'est un sustem de fichier par table je me suis dit autant écouter le fichier directemnt sans déranger mysql. non ?
et que pensez vous du systeme de ficheir log en timeline ?

Berceker United > Il veut aussi les "select" sur les tables ce qui empéche ta méthode. De plus toute bdd est succeptible de buffériser quelques secondes les modifications ce qui retarderait la détection d'une modif. A celà il faut rajouter que toutes les bases ne sont pas en "1 table = 1 fichier" et que même mysql n'utilise qu'un seul fichier pour l'ensemble des tables créé directement en "innodb". A celà enfin il faut rajouter les "tables mémoires" qui, comme le nom l'indique, risquent de n'avoir aucune existance au niveau systéme de fichier.
 
masklinn > C'est vrai que j'avais pas fait gaffe qu'il voulait table par table.

Heuu non ça dépend du type de DB, et lier ton machin à l'implémentation physique de la db c'est une future source de WTF hein  
 
Passe donc par des mécanismes normaux, et vois déjà si les perfos que tu en tires ne sont pas suffisantes (avec un polling correct, pas 1500/µs), ya des chances qu'elles le soient et tu pourras t'arrêter là

Ah ouais sinon tu peux lire le query log aussi lol
 
Mais bon je te conseillerais quand même plutôt de passer par les tables INFORMATION_SCHEMA qui stockent les métadonnées de ta DB, tu te feras vachement moins chier

Merci pour toute ces informations je vais voir pour tenter une solution générique à toute type de sgbd (lecture log) ou passer par les métadonnées.
Merci