hawkmaster: View sinnvoll

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

  1. 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.

    1. 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

      1. 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.

        1. 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

          --
           ☻_
          /▌
          / \ Nur selber lernen macht schlau
          http://bikers-lodge.com
      2. 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

        --
         ☻_
        /▌
        / \ Nur selber lernen macht schlau
        http://bikers-lodge.com
        1. 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
          
          1. 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?

            1. 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

              1. 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

                --
                 ☻_
                /▌
                / \ Nur selber lernen macht schlau
                http://bikers-lodge.com
    2. 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

      --
      Autocomplete has spoiled me to a point where it happens every so often that I encounter a CAPTCHA, and I just type in the first character … and then wait for the rest of the code to be automatically suggested :/
      1. 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.

      2. 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.

      3. 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

        --
        -------------------
        sh:| fo:} ch:? rl:( br:& n4:{ ie:| mo:} va:) js:| de:] zu:| fl:( ss:) ls:& (SelfCode)
        Don't expect anyone else to support you. Maybe you have a trust fund. Maybe you'll have a wealthy spouse. But you never know when either one might run out.  --  Mary Schmich (Chicago Tribune; 1997); Baz Luhrmann (1999), see http://en.wikipedia.org/wiki/Wear_Sunscreen
  2. Добрый день,

    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