En cas de transformation et de quelques questions

iBot · #1 (**permalink**) 01-06-2009

2009-01-05T23: 45:00.017 +02:00

Certaines personnes ont des revenus de vacances avec un surplus d'énergie, sinon, je ne peux pas expliquer pourquoi, aujourd'hui, ma boîte de réception est pleine de mails à partir du même fil de discussion dans l'éternel Yahoo CEP groupe d'intérêt trigerred par une question adressée par Poreza Luis, un étudiant diplômé de l'Université de Coimbra au Portugal. Je prends la liberté de rédiger la question depuis qu'il a été formulé comme une question de système d'échanges, de ce fait, certains des intervenants ont répondu à la négociation liée trucs qui ne vous aident pas à répondre à Luis question, afin obtenir aussi loin que possible de la bourse, je vais fonder le rewriten question dans le marché aux poissons. Ainsi, l'histoire est comme suit: le prix de 1 kg de poisson est déterminé en fonction de l'heure, à la demande, l'offre et de l'état d'esprit général du vendeur. À 10h50, il fait de ce prix à 71, puis à 11h15 le prix est en baisse de plus de 69 changements de 12:00. Il ya un système qui fonctionne dans le temps les fenêtres d'une heure de départ toutes les heures. La demande est de trouver pour la fenêtre de temps 11:00 - 12:00 savoir si le prix de 1 kg de poissons n'a jamais été> 70. La demande est intuitivement que la réponse est oui, puisque le prix dans l'intervalle [10:50, 11:15] a été de 71, mais si on regarde tous les événements qui ont eu lieu à cette fenêtre, il n'y a pas de cas avec une valeur> 70, ainsi actuelle "fenêtre orientée outils --- aucune réponse.

Il ya eu beaucoup de réponses, certains ont même essayé de répondre à la question, par exemple en ajoutant mannequin événements (l'un à la fin de l'intervalle? Chaque minute?) Avec la valeur 71.

Mais - je vais réclamer les affirmations suivantes:

(1). L'obligation donnée n'est pas un événement de traitement modèle.
(2). Les tentatives de traiter en tant que modes de traitement des cas ne sont pas très utiles.
(3). Il est en fait une sorte de temps de requête
(4). Il y mai être un sentiment d'avoir la capacité d'émettre des requêtes en même temps une réponse à des événements (AKA rétrospective des évènements), mais cela doit être fait droit.

Une affirmation - l'exigence n'est pas un événement de traitement modèle. L'événement de transformation est une fonction de configuration des événements, il n'est pas surprenant que Luis a trouvé des difficultés à la phrase en tant que tel. Permettez-moi de prendre deux autres exemples qui ont l'air de la même syntaxe et d'essayer de comprendre quel est le problème ici:

L'organisme gouvernemental exemple: Une agence gouvernementale connue pour ses longues files d'attente pour obtenir le service tente de contrôler la longueur de la file d'attente. Périodiquement, des commis et va compter le nombre de personnes en attente dans la file d'attente. À 10h50 il a trouvé 71 personnes dans la file d'attente, à 11:15 69 personnes dans la file d'attente, pas plus d'exemples de 12:00. Maintenant, la question est - s'il ya eu un moment dans la fenêtre de temps entre [11:00, 12:00], dans lequel le nombre de personnes dans la file d'attente> 70.

Avant de commencer la discussion, regardons un autre exemple, le compte bancaire par exemple.

À 10h50 M. X a déposé 30 $, son solde précédent était de $ 41, qui a fait sa balance $ 71;
à 11h15 M. X a retiré $ 2, l'équilibre a été fixé à $ 69.

Le marché aux poissons par exemple de la syntaxe ressemble point de vue, exactement comme la file d'attente de surveillance par exemple, dans les deux cas, nous avons des événements dans les heures 10:50, 11:15 avec des attributs 71 et 69 respectivement. Toutefois, ils ne sont pas les mêmes, la raison est que le prix dans le marché aux poissons est fixée jusqu'au changé, alors que la longueur de la file d'attente de mai ont été modifiées plusieurs fois monter et descendre depuis l'événement ici n'est qu'un échantillon, et ne couvre pas tous les événements. Ces deux événements, certains d'État (le prix ou la longueur de la file d'attente), mais la sémantique est bien différente. Si nous utilisons la solution de mannequin pour les cas, la file d'attente de la valeur sera probablement mauvais, de plus, nous ne pouvons pas vraiment répondre à la demande dans la file d'attente en cas de «vrais» ou «faux», mais, en réalité, l'échantillonnage périodique est totalement valable type d'événements. En outre, si nous regardons le compte bancaire par exemple, il semble très différent du marché de poisson par exemple - il a deux types d'événements, les événements et ne respectent pas un état, mais ils font rapport sur le changement, et de rendre le changement de valeur ( " delta »). Ainsi, observe les deux événements de dépôt et de retrait, nous allons également ne pas être en mesure de répondre à la question, mais de savoir l'Etat (solde du compte) et le delta (pour le dépôt et retrait) nous obtenons quelque chose qui est sémantiquement similaire pour le marché aux poissons par exemple.

Que pouvons-nous apprendre de ces exemples? d'abord que la propriété «la valeur est la même jusqu'à ce qu'il soit changé" n'est pas une propriété d'un attribut dans l'événement, il est la propriété de l'Etat (données) que mai est créé ou mis à jour par les événements. Cela est vrai pour certains Etats, ce n'est pas vrai pour d'autres. Solution donnée repose sur le fait que l'homme connaît la sémantique de cet état, et écrit des requêtes ad-hoc. Toutefois, ce traitement est de l'État, sur la base de ses propriétés sémantiques, et non des événements.

Assertion deux - Les tentatives de le traiter comme cas de traitement n'est pas utile.

Dans le passé, j'ai blogué sur le marteau et l'ongle. Il ya une tendance d'origine de la personne qui a un produit à essayer et de l'amidon de ses frontières. Cette mai également se retourner, car si vous essayez de faire quelques fonctions que ce produit est bon, et ne pas faire grand travail peut occulter la bonne partie du produit. Solution comme l'ajout de "mannequin événements» est une sorte de piratage. Il abuse de la notion d'événement (depuis mannequin événement n'a pas vraiment le cas), par ailleurs, compte tenu du fait qu'il ne s'agit là que de requête ad-hoc, et il ne peut y avoir beaucoup de ces questions, afin de couvrir l'ensemble, nous devons mai exponentielle nombre mannequin d'événements ... Quoi qu'il en soit, un logiciel de traitement de cas est juste une partie d'image plus grande et, au lieu d'improviser, de piratage ou d'accéder à cette fonctionnalité, elle mai être plus judicieux d'utiliser un produit avec un meilleur ajustement.

Assertion trois - Cette exigence est en fait un temps de requête. Je n'entrerai pas dans le temps des questions maintenant, mais la requête est sur le prix de 1 kg de poisson telles que modifiées par le temps. Il s'agit d'une interrogation existentielle - si certains cherchent principale tient quelque part dans l'intervalle. Autre exemple, le temps de requêtes peuvent être: est-il un jour au cours des 30 derniers jours pendant lesquels le client a retiré plus de 10000 $ en un seul retrait.

Et cet exemple nous ramène à l'affirmation de quatre --- mai il être un sens à quelques cas avec un logiciel de traitement de requêtes temporelles. Exemple, c'est que nous avons un événement qui rend un client "suspect" dans beaucoup de blanchiment, mais nous avons besoin de renfort en regardant certaines requêtes temporelle dans le passé - comme celle écrite ci-dessus ... Je vais écrire sur ce type de fonctionnalités dans une phase ultérieure.

Eh bien - il est 1h15 AM, je ferais mieux de prendre du sommeil, demain est encore une journée bien remplie. Donc, conclusion - tout ce qui semble simple à faire manuellement est simple à faire par un type générique de la pensée, d'autre part - un logiciel de traitement de cas devraient se concentrer sur ce cas de traitement à droite, et ne fait pas mal d'autres choses ... Certains de suivi des affectations Blog - côté

Source ...

Plus d'UNIX et Linux Forum Sujets Vous trouverez peut-être utile
Fil	Thread Starter	Forum	Réponses	Last Post
Le réseau de traitement de l'événement et Transaction Processing	iBot	Complex Event Processing RSS News	0	10-04-2008 10:10 AM
CEP, l'événement sonore et asymétrique Event Processing	iBot	Complex Event Processing RSS News	0	10-02-2008 02:30 AM
Le Kum Bai Ya de traitement de l'événement	iBot	Complex Event Processing RSS News	0	09-01-2008 10:00 AM
Le Web 2.0 et de traitement de l'événement	iBot	Complex Event Processing RSS News	0	08-21-2008 11:20 PM
Simple Event Processing! \u003d Complex Event Processing	iBot	Complex Event Processing RSS News	0	12-16-2007 12:10 PM

Thread Tools	Recherche sur ce Thread
Voir la version imprimable Envoyer cette page	Recherche sur ce Thread: Recherche avancée
Modes d'affichage	Rate this thread
Switch to Linear Mode Switch to Hybrid Mode Fil de Mode	Rate this thread:


	Powered by