View sinnvoll

[hawkmaster]

Hallo zusammen,

Ich hatte bisher noch nie mit Views gearbeitet bzw. sie gebraucht.
In einer MySQL (oder SQLite) Datenbank gibt es eine Tabelle die eine Art "Logtabelle" ist.

Jetzt soll ein externes Programm auf diese Daten zugreifen um die Daten dann weiterzuverarbeiten. (via ODBC)
Würde sich hier nun ein View wie etwa.

CREATE VIEW mylog AS SELECT * FROM logtable;

anbieten?
Dann könnte das externe Programm von diesem View die Daten auslesen und müsste nicht in der Original Tabelle lesen.
Habe ich es richtig verstanden, dass ein View immer den aktuellen Zustand der original Tabelle wiederspiegelt? Wenn also in der Tabelle "logtable" 5 inserts gemacht werden, dann ist dies auch sofort im View sichtbar?

vielen Dank und viele Grüße
hawk

[Encoder]

Dann könnte das externe Programm von diesem View die Daten auslesen und müsste nicht in der Original Tabelle lesen.

Wo wäre das Problem in der Original Tabelle zu lesen?

Habe ich es richtig verstanden

Nein. Eine View bietet eine Sicht (= View) auf eine Tabelle. Du kannst damit nur bestimmte Spalten in der View zeigen und andere ausblenden. Oder du kannst in der View was aus anderen Tabellen dazu joinen. Aber die Daten sind nur einmal da, nämlich in der Tabelle.

[hawkmaster]

Hallo,

danke dir.

Wo wäre das Problem in der Original Tabelle zu lesen?

Kein echtes Problem. In MySQL könnte man zur Not reine Lese-Rechte nur für diese eine Tabelle setzen, so das man via ODBC den Zugriff auf die gesamte andere DB unterbieten könnte. Bei SQLite
geht das halt nicht.
Eigentlich ist es ja nur ein Lesezugriff aber man weiss ja nie. Wenn dann je einmal irgend etwas mit den Daten wäre, weiss man nie, war es das externe Programm, oder war es das eigene.

vielen Dank und viele Grüße
hawk

[dedlfix]

Tach!

Wo wäre das Problem in der Original Tabelle zu lesen?
Kein echtes Problem. In MySQL könnte man zur Not reine Lese-Rechte nur für diese eine Tabelle setzen, so das man via ODBC den Zugriff auf die gesamte andere DB unterbieten könnte. Bei SQLite geht das halt nicht.

Eine View ist kein Sicherheitsfeature. Wer die View lesen kann, kann auch die Originaltabelle lesen. Das ist sogar Voraussetzung (beim MySQL). Wenn du die Datei nicht auf Nur-Lesen umstellen kannst, verhindert auch eine View keinen Schreibzugriff.

dedlfix.

[Tom]

Hello,

Eine View ist kein Sicherheitsfeature. Wer die View lesen kann, kann auch die Originaltabelle lesen. Das ist sogar Voraussetzung (beim MySQL). Wenn du die Datei nicht auf Nur-Lesen umstellen kannst, verhindert auch eine View keinen Schreibzugriff.

Dafür gibt es dann ja die Stored Procedure

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Wo wäre das Problem in der Original Tabelle zu lesen?

Zugriffsrechte, unerwünschte Offenlegung innerer Strukturen, usw.

Kein echtes Problem. In MySQL könnte man zur Not reine Lese-Rechte nur für diese eine Tabelle setzen, so das man via ODBC den Zugriff auf die gesamte andere DB unterbieten könnte. Bei SQLite
geht das halt nicht.

Man könnte auch eine Stored Procedure dafür anlegen, die dann auch einen Logeintrag für den Zugriff erstellt oder sogar ein Abbild (Snapshot) der angeforderten Daten ablegt.

Eigentlich ist es ja nur ein Lesezugriff aber man weiss ja nie. Wenn dann je einmal irgend etwas mit den Daten wäre, weiss man nie, war es das externe Programm, oder war es das eigene.

Man möchte aber ggf. wissen, wer wann auf welche Daten zugegriffen hat.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hawkmaster]

Hallo zusammen,

vielen Dank an alle für die Hilfe und Infos.

Man könnte auch eine Stored Procedure dafür anlegen, die dann auch einen Logeintrag für den Zugriff erstellt oder sogar ein Abbild (Snapshot) der angeforderten Daten ablegt.

Bei MySQL wäre das event. auch eine Möglichkeit. Leider geht das aber nicht bei SQLite.

Ich habe jetzt mal etwas anderes versucht.(nur mal so zum Test)

In einer neuen zweiten MySQL DB wurde eine einzige Tabelle angelegt, die die gleiche Struktur hat, wie die original Log Tabelle.
Dann habe ich in der Haupt DB einen INSERT AFTER Trigger erstellt.
Mit einem ~~~sql

INSERT INTO backupdb.logtab
SELECT *
FROM logtab_ori
WHERE id NOT
IN ( SELECT ..

  
mache ich nun einen Abgleich zwischen der Haupt DB Log Tabelle und der zweiten DB.  
  
Ich war erstaunt das es tatsächlich funktioniert zwischen den DBs.  
Leider halt auch hier wieder: Bei SQLite gehen Trigger nur innerhalb der gleichen DB.  
  
viele Grüße  
  
hawk

[Encoder]

Das sagt mir aber schon dass ich nicht ganz so falsch lag mit meiner Vermutung über dein Vorhaben.
Du willst also ein Backup deiner Tabelle anlegen. Meine Aussage war (bzw. hätte sein sollen, war doof formuliert) dass eine View keine Backuptabelle ist.

Dir wurde in den Diskussionen wahrscheinlich einiges klarer, aber was du genau vorhast ist glaub ich immer noch nicht so klar. Was genau hast du vor? Eine Sicherungstabelle anlegen die Daten behält, falls jemand sie aus der Originaltabelle löscht?

[hawkmaster]

Hallo

.... dass eine View keine Backuptabelle ist.

Das ist mir klar. Vielleicht ist Backuptabelle auch der falsche Ausdruck.

Was genau hast du vor? Eine Sicherungstabelle anlegen die Daten behält, falls jemand sie aus der Originaltabelle löscht?

Tom hatte es hier ganz gut formuliert:
"Zugriffsrechte, unerwünschte Offenlegung innerer Strukturen, usw..."

Ich will eigentlich ungern jemandem fremden oder einem fremden Tool meine gesamte DB zur Verfügung stellen. Es könnte ja vielleicht irgend wann die doofe Situation geben, dass es Probleme mit der DB oder dieser Tabelle gibt. Dann wird immer ein Streitpunkt sein, war es das eigene Programm oder event. das externe? Daher mein Versuch / Test mit einer Art "Spiegelung" der eigentlichen "logtabelle" in eine separate DB. Mir ist bewusst, dass dies nicht ideal ist. So aber könnte man dem fremden Tool sagen "Nimmt diese DB und diese Tabelle zum auslesen der Daten" und die original DB würde unberührt bleiben.

vielen Dank und viele Grüße
hawk

[Tom]

Hello,

Ich will eigentlich ungern jemandem fremden oder einem fremden Tool meine gesamte DB zur Verfügung stellen. Es könnte ja vielleicht irgend wann die doofe Situation geben, dass es Probleme mit der DB oder dieser Tabelle gibt. Dann wird immer ein Streitpunkt sein, war es das eigene Programm oder event. das externe? Daher mein Versuch / Test mit einer Art "Spiegelung" der eigentlichen "logtabelle" in eine separate DB. Mir ist bewusst, dass dies nicht ideal ist. So aber könnte man dem fremden Tool sagen "Nimmt diese DB und diese Tabelle zum auslesen der Daten" und die original DB würde unberührt bleiben.

Dann ist bei MySQL die Nutzung einer "Stored Routine" das angeratene Mittel. Da muss nur in der DB-Rechtestruktur freigeschaltet werden, dass der User Zugriff auf die Stored Routine hat, nicht auf die eigentlichen Tabellen. Und bei der Erstellung der Stored Routine wird festgelegt, dass diese z.B. mit den Rechten des Erstellers auf die DB zugreift.

Damit sind die datenhaltene und die präsentierende Schicht voneinander getrennt. Und aßerdem kann man in der Stored Routine oder einer Function auch für Selects ein Insert in einer Log-Tabelle erzeugen.

Ich mach das immer so, wenn ich MySQL-DB-Daten für Fremdanwendungen bereit stelle.

Die Stored Routine kann auch Parameter entgegennehmen, so dass man damit die Abfragen auch noch kontrolliert steuern kann.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

Habe ich es richtig verstanden
Nein.

Doch.

Hättest du nicht so sinnentstellend gekürzt, wäre das auch offensichtlicher.

Habe ich es richtig verstanden, dass ein View immer den aktuellen Zustand der original Tabelle wiederspiegelt? Wenn also in der Tabelle "logtable" 5 inserts gemacht werden, dann ist dies auch sofort im View sichtbar?

So ist es.

Eine View bietet eine Sicht (= View) auf eine Tabelle. Du kannst damit nur bestimmte Spalten in der View zeigen und andere ausblenden. Oder du kannst in der View was aus anderen Tabellen dazu joinen. Aber die Daten sind nur einmal da, nämlich in der Tabelle.

Dem hat ja auch niemand widersprochen. (Sofern du nicht in “widerspiegeln” hineinlesen willst, dass die Daten in Kopie vorgehalten würden – aber ich glaube nicht, dass hawkmaster das so gemeint hat.)

MfG ChrisB

[Encoder]

Den Satz "habe ich richtig verstanden..." hab ich tatsächlich falsch zitiert, tut mir leid!
Das nicht verstanden haben muss auf den Satz davor bezogen werden.

(Sofern du nicht in “widerspiegeln” hineinlesen willst, dass die Daten in Kopie vorgehalten würden – aber ich glaube nicht, dass hawkmaster das so gemeint hat.)

Ich hab das in "und müsste nicht in der Original Tabelle lesen" hineingelesen. Vor allem das und auch der restliche Text liest sich für mich schon als würde hawkmaster in einer View etwas sehen, das die Daten unabhängig von der Tabelle nochmals separat hält.
Vielleicht erfahren wir ja noch wie er das wirklich gemeint hat.

[Kuddel]

Moin,

Habe ich es richtig verstanden, dass ein View immer den aktuellen Zustand der original Tabelle wiederspiegelt? Wenn also in der Tabelle "logtable" 5 inserts gemacht werden, dann ist dies auch sofort im View sichtbar?

So ist es.

Aus der Fragestellung heraus würde ich dir da recht geben. Die Daten werden laut Definition der View immer neu abgefragt und nicht zwischengespeichert (Ad-hoc). Sie können aber auch noch transformiert, gefiltert oder wie auch immer aufbereitet werden. So gesehen haben die Daten nichts mehr mit der eigentlichen Tabelle zu tun.

[Rouven]

Hello,

Dem hat ja auch niemand widersprochen. (Sofern du nicht in “widerspiegeln” hineinlesen willst, dass die Daten in Kopie vorgehalten würden)

der technischen Vollständigkeit halber: in einigen DBMS existiert noch das Konzept der materialized views bei denen dann tatsächlich kopiert/gecached wird. Das ist aber nicht der Standardfall bei einem CREATE VIEW...

Vgl. hierzu Materialized View (Wikipedia)

MfG
Rouven

[T-Rex]

Добрый день,

um direkt auf deinen Titel einzugehen, ein View ist nur dann sinnvoll, wenn du eine Abfrage vereinfachen kannst. Wenn du z.B. öfters einen Join zwischen 5 Tabellen brauchst, dann legst du dafür eine View an. Dann reduziert sich die Abfragelänge und Komplexität des Querys sehr stark. Und genau so sehe und behandle ich Views, es sind gespeicherte Abfragen. Demnach lässt sich die Frage ob man Originaldaten sieht auch eindeutig mit ja beantworten.

Gruß
original
T-Rex