08-24-2008
|
|
Forum Robot Girl
|
|
|
Join Date: Sep 2000
Posts: 22.203
|
|
|
Op Event winkels en Temporele Databases
2008-08-24T19: 37:00.004 +03:00
Ik ben een ouderwetse man die voert zakdoeken, zoals deze, waar hij gaat, dan is het handig voor meerdere toepassingen, toch -, terwijl in het verleden, alle warenhuizen in Israël die zakdoeken en het was nogal een populair product, voor sommige Daarom ging uit de mode, en ik heb harde tijd voor de vernieuwing van de inventaris van zakdoeken, en in dit opzicht, ik wou dat ik kon stap voor een minuut in het verleden koopt twee tientallen zakdoekjes en terugkeer. In het verleden ben ik betrokken geweest bij de werkzaamheden rond temporele databases en zelfs co-edited een boek op dit gebied. Temporele databases had twee grote doelstellingen:
(1). Houd historische gegevens, en kunnen gemakkelijk terugvinden van deze gegevens
(2). In staat stellen tot het aangaan van zoekopdrachten "als van" enig punt in de tijd, dat wil zeggen kwestie query, dat rekening houdt met de informatie die beschikbaar was op een bepaald punt in de tijd (niet gezien vanaf "nu") - weer terugkeren naar het verleden.
Men kan zich afvragen waarom ik schrijven over temporele databases van vandaag, en - het vraagstuk van de temporele databases komt terug wanneer het denken over "evenement winkels", ik weet dat sommige van mijn collega's database niet graag de term "evenement opslaan" of " evenement repository ", want het omvat niet expliciet het woord" database ", maar voor mij, met behulp van DBMS is slechts een mogelijke uitvoering, terwijl andere, zoals net cache zijn ook mogelijk - maar dit is een onderwerp voor een andere discussie.
Hoe dan ook - waarom hebben we behoefte aan een "gebeurtenis slaan" - in sommige gevallen moeten we behouden historische gebeurtenissen en te gebruiken, in sommige gevallen zelfs van toepassing patroon detectie op gebeurtenissen in het verleden. Voor controledoeleinden kunnen we willen ook kwestie "als van" queries. Merk op dat temporele representatie van evenementen kan worden gedaan volgens meerdere temporele dimensies (zie discussie over de temporele aspecten van de gebeurtenissen). Een van de kenmerken van temporele databases zijn dat zij "append slechts" databanken, zin: database records kunnen worden toegevoegd, maar niet gewijzigd of verwijderd; wijzigingen en schrappingen zijn logische operatoren die een andere gevallen houden de oude. Dit is gekoppeld aan een van de eigenschappen van evenementen -- onveranderlijkheid, Dat is eigenlijk een controversiële eigenschap die nog discussie over de - in welke omstandigheden dat nodig is. Temporele databases lijken een goede manier te vertegenwoordigen historische gebeurtenissen.
Sommige sluiten opmerkingen:
(1). Huidige DBMS niet ondersteunen temporele databases als primitief, hoewel temporele databases zijn gebouwd als een tweede laag boven hen.
(2). Niet alle evenementen moeten worden hardnekkige voor historische verwerking, dit is een eigenschap van het evenement-type, en haar beleid voor het bewaren. Verschillende gebeurtenissen moeten blijven voor verschillende doeleinden.
(3). De kwestie van welke taal moet worden gebruikt voor het verwerken van "event winkels" is ook een kwestie van mening, sommige vinden dat SQL is het antwoord (maar voor een aantal patronen is het een lastige taal), er is een poging tot uitbreiding van de SQL-taal met patroon extensies, hier zal ik citeer een verstandig persoon, Paul Vincent, die schreef in een voetnoot bij dit bericht : Dit zal met name goed nieuws voor degenen die graag hun SQL statements uit te voeren op meerdere pagina's ... Een andere optie is het gebruik van on-line-patroon taal die wordt gebruikt voor on-line patronen, en vertaald naar SQL (of een van zijn varianten).
Er zijn verschillende problemen die nog moeten dieper discussie - maar genoeg voor vandaag.
Bron ...
|
Meer UNIX en Linux Forum Onderwerpen Misschien vindt u Helpful
Powered by 
Threaded Mode
