SQL Schichtenwirrwarr
Hi,
es gibt ja verschiedene SQL-Ausführungsschichten.
Habe ich das richtig hier? (Absteigend nach zunehmender granularität)
- Pool
- Session
- Connection
- Transaction
- Savepoint
- Commit
- Statement
Ich bin mir jedoch bei Savepoint und Transaction nicht sicher.
Kommt das so hin?
es gibt ja verschiedene SQL-Ausführungsschichten.
Habe ich das richtig hier? (Absteigend nach zunehmender granularität)
- Pool
- Session
- Connection
- Transaction
- Savepoint
- Commit
- Statement
Ich bin mir jedoch bei Savepoint und Transaction nicht sicher.
Kommt das so hin?
Verstehe nicht ganz, was du meinst.
Zu einer Transaction gehört, wenn ich mich nicht irre, immer ein Commit. Ein Savepoint kann auch nur Bestandteil einer Transaction sein ( soweit ich weiß). Aus meinem Verständnis gehören Commit und Savepoint zu einer Transaction, sind hier aber nicht verschiedene Schichten in Bezug auf statements oder session.
Transactions würde ich mal als 'Bündel' von Statements bezeichnen.
Eine nicht unterbrochene 'Connection' ist doch automatisch meist auch eine Session, es sei denn, zwischendurch wird der Nutzer gewechselt. Ich glaube, selbst beim Wechsel des Nutzers, bleibt die Session genauso, wie die Connection bestehen. Es wird halt nur der neue Nutzer mit den ihm gewährten Rechten mit der alte Session assoziiert. Wenn ich mich jetzt nicht ganz irre, ist session (zumindest bei mysql) eigentlich gleichbedeutend mit 'connection'. Weiß allerdings nicht sicher, was mysql bei einem Reconnect nach einer unterbrochenen Verbindung macht. Kann sein, dass dann die alte Session weiterverwendet wird
. Zumindest bin ich mir ziemlich sicher, dass im internen Mysql-Protokoll keine Session-Daten übermittelt werden. Das betrifft dann aber schon den Bereich des Connection-Managements, was Angelegenheit des Connection-Pools ist.
Unterhalb oder neben Statements würden noch die Views gehören. Aber letztlich sind nur Statements und Views zwei verschiedene Schichten der Präsentation der gleichen Daten.
Zu einem Auto gehört normalerweise auch ein Lenkrad. Dessshalb gehört ein Lenkrad aber nicht zu den verschiedenen Schichten von Fahrzeugen.
Ich verstehe deine Kriterien nicht, nach denen du die Begriffe verschiedenen Schichten zuordnest.
Zu einer Transaction gehört, wenn ich mich nicht irre, immer ein Commit. Ein Savepoint kann auch nur Bestandteil einer Transaction sein ( soweit ich weiß). Aus meinem Verständnis gehören Commit und Savepoint zu einer Transaction, sind hier aber nicht verschiedene Schichten in Bezug auf statements oder session.
Transactions würde ich mal als 'Bündel' von Statements bezeichnen.
Eine nicht unterbrochene 'Connection' ist doch automatisch meist auch eine Session, es sei denn, zwischendurch wird der Nutzer gewechselt. Ich glaube, selbst beim Wechsel des Nutzers, bleibt die Session genauso, wie die Connection bestehen. Es wird halt nur der neue Nutzer mit den ihm gewährten Rechten mit der alte Session assoziiert. Wenn ich mich jetzt nicht ganz irre, ist session (zumindest bei mysql) eigentlich gleichbedeutend mit 'connection'. Weiß allerdings nicht sicher, was mysql bei einem Reconnect nach einer unterbrochenen Verbindung macht. Kann sein, dass dann die alte Session weiterverwendet wird
. Zumindest bin ich mir ziemlich sicher, dass im internen Mysql-Protokoll keine Session-Daten übermittelt werden. Das betrifft dann aber schon den Bereich des Connection-Managements, was Angelegenheit des Connection-Pools ist.Unterhalb oder neben Statements würden noch die Views gehören. Aber letztlich sind nur Statements und Views zwei verschiedene Schichten der Präsentation der gleichen Daten.
Zu einem Auto gehört normalerweise auch ein Lenkrad. Dessshalb gehört ein Lenkrad aber nicht zu den verschiedenen Schichten von Fahrzeugen.
Ich verstehe deine Kriterien nicht, nach denen du die Begriffe verschiedenen Schichten zuordnest.
Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »ospx« (16. November 2009, 20:04)
Ist schon richtig, danke.
Eigentlich nach zeitlicher Reihenfolge beim Initialisieren.
Zuerst den Pool bauen, dann die Verbindung eröffnen, dann dass Statement usw.
Das mit den Views finde ich wichtig.
Gut, Savepoints und Transactionen muss ich dann parallel setzen,
und Views, Commits und Statements auch.
Also:
- Pool
- Session
- Connection
- Transaction und Savepoint
- Statement, View und Commit
Eigentlich nach zeitlicher Reihenfolge beim Initialisieren.
Zuerst den Pool bauen, dann die Verbindung eröffnen, dann dass Statement usw.
Das mit den Views finde ich wichtig.
Gut, Savepoints und Transactionen muss ich dann parallel setzen,
und Views, Commits und Statements auch.
Also:
- Pool
- Session
- Connection
- Transaction und Savepoint
- Statement, View und Commit
Norvares
unregistriert
Also ein Savepoint gehört IMMER zu einer Transaction, ansonsten macht der einfach keinen Sinn... Darüber hinaus ist ein View ein fest definiertes Statement, welches nicht immer neu geparst werden muss und daher schneller ist. Darum würde ich sagen das View auf einer Ebene mit Transaction ist bzw. auf jeden Fall höher als das Statement.


