RAIB - Versionsgeschichte

OrgaMon: /* granid */

2013-10-18T15:57:08Z

granid

← Nächstältere Version		Version vom 18. Oktober 2013, 17:57 Uhr
Zeile 349:		Zeile 349:
	//		//
	//		//

			== Neu: CLUB ==

			In Zukunft sollen Parameter Eingabedialoge abfragbar sein. (Ev. mit Historie und default Belegungen)

			In Zukunft sollen Dimensionen vordefiniert sein (Artikel,Belege, Verkäufe, Personen).

			In Zukunft sollen Attribute angebbar sein (Artikel.Anlage > -3 Monate, Person.Alter > 40).

			In Zukunft sollen Betriebsbegriffe vordefinierbar sein.<br>
			Umsatz(eines Artikel) (select MENGE_GELIEFERT from POSTEN-Club)<br>
			Umsatz(einer Person) (select DAVON_BEZAHLT from BELEG-Club)<br>
			<br>
			der POSTEN-Club kann dann einfach * sein, oder wieder selektiert.
			n-Idee: Jede Dimension hat üben, in die manden Abfrage-Faden flechten kann.
			OLAP-Admins definieren Clubs, Dimensionen und en.
			Zeiträume sollten nun (Jahrgenauer \|Taggenauer \| Monatgenauer \| Wochengenauer) kummuliert werden. Das ist die Granularität Summe ist die größe Körnung.

			Club: A (maybe empty) List of Members
			Rule: A piece of deterministic logical code that decides, if a record is a Member or not. Club uses Rules to define if one is a member or not.
			Mem ber: A Record that is a part of one ore more clubs
			isMember(): Answer the Question if a En
			Field: space in a Record that can store a value , or can be empty
			Record: One Line in a Table
			Table: The Collection of Lines
			Welcome: Somewhat happend, you are now gain membership of a club
			Dependencies: A stored hint, that the system has to check again some rules to say welcome or good bye
			transformer: a piece of code that calculates a in64 from a key of
			Transaction: a of atoms
			atom: a single changing operation done to the base

			== Neu: Begriff ==

			Begriffe wie "Kunde" und "Umsatz" oder "Sortimentsbewegung" werden als OLAP-Statements definiert. Ein zentrale OLAP Abfrage könnte nun Fragestellungen mit Hilfe von "Begriffen" formulieren. Beispiel:

			* Alle Kunden mit Sortimentsbewegung in den Sortimenten "A" und "B" im Zeitraum Januar bis März 2010

			Die Auflösung würde so erfolgen, dass zunächst die Begriffe

			# 1. Schritt: Begriffstabellen bilden
			Kunden('01.01.2010','31.03.2010')
			Sortimentsbewegung('01.01.2010','31.03.2010')

			ausgelöst werden. Diese Begriffs-Eregbnise werden in temporären Ergebnistabelle zuwischengespeichert. Alles über EIN zentrales online SQL-Statement lösen zu wollen hat sich als unwirtschaftlich herausgestellt.

			# 2. Schritt
			select PERSON_R from Kunden
			join Sortimentsbewegung where
			(Kunden.PERSON_R=Sortimentsbewegung.PERSON_R) and
			(
			(Sortimentsbewegung.SORTIMENT_R='A') or
			(Sortimentsbewegung.SORTIMENT_R='B') or
			)

			würde man bei firebird alles in eine gemeinsame Transaktion packen, so könnte man "CREATE GLOBAL TEMPORARY TABLE ON COMMIT DELETE" machen.

OrgaMon: /* Club-Pages */

2012-02-29T13:54:01Z

Club-Pages

← Nächstältere Version		Version vom 29. Februar 2012, 15:54 Uhr
Zeile 289:		Zeile 289:

	== Club-Pages ==		== Club-Pages ==

			"Ich hab schon mal auf einer Grafik gesehen, dass die Index-Values mit Duplikationen irgendwie mit in dem Suchbaum gespeichert sind, ich denke das hat traditionelle Gründe. Die richtige Implementierung ist es, nur die distinct Werte der Index-Values genau einmal zu speichern, jeder Index-Value sollte dann auf eine Mitgliederliste verweisen. Die Null Values gehören nicht in den Suchbaum und sollten die Index-Performanche nicht beinflussen, sie gehören in die Mitgliederliste "NULL".
			"

	Club Pages are Record-Reference Index-Pages telling if a Record is Part of a Club or not. Updating a Record may corse a "enter" oder "leave" club event. Delete is a "leave" is it was a memeber. Insert may be "enter".		Club Pages are Record-Reference Index-Pages telling if a Record is Part of a Club or not. Updating a Record may corse a "enter" oder "leave" club event. Delete is a "leave" is it was a memeber. Insert may be "enter".

OrgaMon: /* Update a REcord, if unchanged */

2011-02-23T14:19:48Z

Update a REcord, if unchanged

← Nächstältere Version		Version vom 23. Februar 2011, 16:19 Uhr
Zeile 93:		Zeile 93:
	New inserted Records get their (first) RID from the GID		New inserted Records get their (first) RID from the GID

	== Update a ~~REcord,~~ if unchanged ==		== Update a Record: if unchanged ==

	sometimes Applications or users need long time to "change" a record. At "first" the Applications read all Record-Data from Db-Table. Then after 5 Minutes they post their changed Record-Fields by a update statement.		sometimes Applications or users need long time to "change" a record. At "first" the Applications read all Record-Data from Db-Table. Then after 5 Minutes they post their changed Record-Fields by a update statement.

OrgaMon: /* Update a REcord, if unchanged */

2011-02-23T14:19:27Z

Update a REcord, if unchanged

← Nächstältere Version		Version vom 23. Februar 2011, 16:19 Uhr
Zeile 94:		Zeile 94:

	== Update a REcord, if unchanged ==		== Update a REcord, if unchanged ==

			sometimes Applications or users need long time to "change" a record. At "first" the Applications read all Record-Data from Db-Table. Then after 5 Minutes they post their changed Record-Fields by a update statement.
			If the Data-Mask is complex, than even more TABLES may be affected by the update. If the application not only read the REcord-Data but also read the GID, it can post an update "on the knowledge state of 8383892". If the knowledge-Sate has gone further, the update will fail - the user may be informed that the unlying data has changed in the meantime and the update is not possible by know.
			The App may present a diff of the "local" and new "remote" Record - let the user decide how the merge could look like.

	update TABLE1 set		update TABLE1 set

OrgaMon: /* Deterministic SQL */

2011-02-23T14:05:46Z

Deterministic SQL

@@ Zeile 63: / Zeile 63: @@
 # Because of relyable playbacks.
 # Because of an exetuting swarm, resulting in a 100% identical database
 == Statement-Log-Packets ==

Root am 15. Oktober 2010 um 13:40 Uhr

2010-10-15T13:40:27Z

← Nächstältere Version		Version vom 15. Oktober 2010, 15:40 Uhr
Zeile 272:		Zeile 272:

	http://www.linbit.com/		http://www.linbit.com/

			== granid ==

			// a simple artefact was found in space
			// just a small stone
			// a texture like granit
			// a first it seems like rauschen
			// than a set of algorithems
			// where extracted by the intelligence
			//
			// i am granid. a database server. i am open source
			//
			// several elements mixed up
			// by one spirit
			// one force arranged granulat
			// big pressure, fire and heat
			// then - silence - one piece
			// a stone was born
			//
			// performance, stability, transparence
			// no past, only the future
			// no limitations, only the chanche to make it faster
			//
			// ANFICO - The Language Extender
			// BLAGER - The Binary Lager
			// D64 - 64 Bit Data-Manager
			//
			//
			// Data: <UInt32 TimeStamp> <UInt64 RecordChangeTag>
			//
			//

Root: /* Club-Pages */

2010-07-22T14:00:00Z

Club-Pages

← Nächstältere Version		Version vom 22. Juli 2010, 16:00 Uhr
Zeile 257:		Zeile 257:


	Clubs speed up OLAP because if a Statement "where" Condition match a Club-Rule~~, result is easy~~.		Clubs speed up OLAP because if a Statement "where" Condition match a Club-Rule.

			join CLUB$$INCOME on
			(PERSON.RID=CLUB$$INCOME.PERSON_R)

	== Project names alternatives ==		== Project names alternatives ==

OrgaMon am 30. Juni 2010 um 13:44 Uhr

2010-06-30T13:44:41Z

@@ Zeile 244: / Zeile 244: @@
   Aa:Cache 261526271 !if unchanged!
   Ab:20,01 Euro (=Cache Identifier 261526272) !if changed!
 == Project names alternatives ==

OrgaMon: /* Project names alternatives */

2009-03-26T11:39:38Z

Project names alternatives

← Nächstältere Version		Version vom 26. März 2009, 13:39 Uhr
Zeile 247:		Zeile 247:
	== Project names alternatives ==		== Project names alternatives ==

	"firebird D" ~~(Firebirdie)~~		Firebirdie from "firebird D", "D" for Deterministic Mode


	GenerationsCount: SQL Statement, das mich dazu gemacht hat.		GenerationsCount: SQL Statement, das mich dazu gemacht hat.

OrgaMon am 25. Februar 2009 um 09:54 Uhr

2009-02-25T09:54:42Z

← Nächstältere Version		Version vom 25. Februar 2009, 11:54 Uhr
Zeile 225:		Zeile 225:
	* Trick 1: Always use cash if since last "R" there was no "T"		* Trick 1: Always use cash if since last "R" there was no "T"
	* Trick 2: On first insert in cash, build a dependecy-tree, on what the Answers depends on, if asked again, only check tree, if not more developed than the saved version -> use cashed answer		* Trick 2: On first insert in cash, build a dependecy-tree, on what the Answers depends on, if asked again, only check tree, if not more developed than the saved version -> use cashed answer
			* Hint: While executing "W" Statement cut Cache-trees
	* Trick 3: Cash-Questions are parallel to Answers, we have an unlimited Count of CPUs.		* Trick 3: Cash-Questions are parallel to Answers, we have an unlimited Count of CPUs.

Zeile 233:		Zeile 234:
	A "R" Statement can be cashed if "Context" Bubble still is alive		A "R" Statement can be cashed if "Context" Bubble still is alive

	== the new I/O Model ==		== the new I/O Model: IO+C (Input Output Cacheable) ==

	* extends the classic I/O Modell by the possibility to Ask the I for a List of dependencies of the I		* extends the classic I/O Modell by the possibility to Ask the I for a List of dependencies of the I

			Q:"select SUM(BETRAG) FROM KOSTEN where Cond" into Cache
			A:20,00 Euro (=Cache Identifier 261526271)
			Qa:"select SUM(BETRAG) FROM KOSTEN where Cond" from Cache
			Qb:Cache 261526271 still valid?
			Aa:Cache 261526271 !if unchanged!
			Ab:20,01 Euro (=Cache Identifier 261526272) !if changed!

	== Project names alternatives ==		== Project names alternatives ==