Diskussion:Sicht (Datenbank)

message: Wie wärs mit Literaturbelegen? (nicht signierter Beitrag von 62.134.55.194 (Diskussion | Beiträge) 13:17, 20. Apr. 2010 (CEST)
thread_title:  Quellen? 

message: Ahoi, ich würde gerne das Wort "View" generell durch das schöne deutsche Wort "Sicht" ersetzen. Einwände bitte, bevor ich es ändere ;-) Fragment 13:23, 6. Aug 2005 (CEST)
replies: text: Naja, in SQL heisst es eben create View und nicht erzeuge Sicht. Es ist sicher ein gutes Ziel unsere Sprache zu verwenden, wo immer es geht, aber man sollte es nicht krampfhaft machen. Bei Sicht fuer View bin ich aus obigen Grund etwas unentschlossen. Gruss -- sparti 21:40, 6. Aug 2005 (CEST)
replies: text:  Das SQL-Statement bleibt natürlich so wie es ist, und das Wort "View" wollte ich auch nicht komplett unterschlagen. Ich ändere das morgen, kannst es ja zurücknehmen, wenn es Dir nicht passt. Ahoi, Fragment 00:24, 7. Aug 2005 (CEST)

text:  Ahoi, habe das also gemacht. Heuer&Saake benutzen übrigens auch durchgängig "Sicht", sogar in "materialisierte Sichten". Ich glaube übrigens, dass das ganze DB-Thema ziemlich gut eingedeutscht ist! Fragment 22:19, 7. Aug 2005 (CEST)

text:  Was ist nun mit der Übersetzung? Also ich bin gerade dabei mich auf meine DB1-Klausur vorzubereiten und wollte mal etwas von den Skripten weg und fand diesen Artikel. Also das SQL-Statement heißt sicherlich VIEW, aber der Befehl "CREATE TABLE" erzeugt nunmal eine "Tabelle" und keine "Table", oder? Warum darf also "CREATE VIEW" keine Sicht erzeugen? Bei uns im Skript heißt das übrigens durchweg "Sicht" ("Definieren Sie in SQL eine Sicht, die ..."). Ich würde beispielsweise den ersten Satz so beginnen: "Eine Sicht (englisch: view) ist eine logische Relation..." Da hier seit 2005 keiner mehr diskutiert hat, werde ich, wenn keine Einwände sind, morgen View in den Sätzen durch Sicht ersetzten. --Felbion 19:32, 11. Sep. 2009 (CEST)
replies: text:  Übrigens heißt der Artikel ja "Sicht" und nicht "View", warum wird dieses Wort dann so verächtlich gemieden? --Felbion 19:38, 11. Sep. 2009 (CEST)
thread_title:  "View" übersetzen 

message: Ahoi nochmal, zu Updateanomalien kann man ggfs. noch das eine oder andere sagen, da gibt es noch so was Furchtbares wie die Theorie änderbarer Sichten. Wenn das jemals ausgebaut wird, würde ich empfehlen, das ganze in einen eigenen Artikel zu verschieben. Fragment 13:56, 6. Aug 2005 (CEST)
replies: text: Habe das Wort "Updateanomalie" wieder herausgenommen, das hat hier nix zu schaffen, sondern gehört zu den Normalformen. Fragment 15:35, 13. Aug 2005 (CEST)
thread_title:  Updateanomalien 

message: Im derzeitigen Artikeltext steht: "MVs sind Views, die physikalisch gespeichert werden, um Zugriffe zu beschleunigen." 
Bitte mal präzisieren! Wird auf Massenspeicher gespeichert (was unterscheidet eine MV dann von einer "normalen" Tabelle?)?
Oder wird quasi unbegrenzt im RAM gehalten (was unterscheidet eine MV dann von einer "normalen" View?)?-- Lexer.W 16:02, 25. Jun. 2009 (CEST)
thread_title:  Materialized View - Bitte um Präzisierung

message: Warum sollten View für den Datenschutz nicht verwendet werden? Vor genau so einem Problem stehe ich nämlich - es geht um ein Mailsystem:
* Es gibt eine Tabelle mit allen POP3/IMap-Accounts für verschiedene Domains (bla@fasel.local, test@test.irgendwas..)
* Bestimmte Datenbankbenutzer, die zu der entsprechenden Gruppe gehören, sollten die Konten "ihrer" Domain bearbeiten/einsehen können, aber nicht die anderen Konten der anderen Domains.
Die einfachste Lösung ist hier eine Sicht/View - die Gruppe "fasel.local" (mit Benutzer A, B und C) haben nur Recht, auf der View "v_fasel.local"  select/insert/update/delete auszuführen (letztere mit sowas wie Triggern), die eigentlichen Tabellen sehen sie nicht (und durch die filternde View auch nicht andere Nutzerdaten).
Das ist doch durchaus ein klassischer Fall von Datenschutz? --Mark Nowiasz 18:14, 7. Okt. 2009 (CEST)
replies: text: Exakt diesselbe Frage wollte ich ebenfalls stellen und offenbar konnte sie in den letzten fünf Jahren keiner beantworten. Ich setze mal den Quellenbaustein. --Suricata (Diskussion) 10:09, 19. Feb. 2014 (CET)

text: Für mich wäre diese Information auch sehr wichtig. Ich persönlich vermisse den Aspekt, dass Views eben genau für diesen Fall eingesetzt werden können. Das macht vor allem für den Anwendungsfall Sinn, wenn man eine große "Datenbasis" besitzt, auf die mehrere Software-Produkte zugreifen. Vergibt man für jede Software eigens für den Anwendungszweck erstellte Views und legt für jede Software einen Benutzer an, der nur die für die Software benötigten Views verwenden darf, hätte man sogar noch ein Security-Vorteil: Sollte eine Software fehlerhaft laufen oder "gehackt" worden sein, können Fehler oder "Angreifer" im schlimmsten Fall nur bestimmte Daten verwenden können, jedoch niemals Einsicht in die gesammte Datenbank haben. (Vielleicht als Anreiz, wenn jemand hierzu nach Quellen recherchiert :) ) --EifX (Diskussion) 14:11, 19. Jun. 2014 (CEST)
replies: text:  Natürlich können Views (Sichten) – am besten in Verbindung mit Rollen – für den Datenschutz / Datentrennung eingesetzt werden (Beleg etwa hier). Das derzeit im Artikel stehende ist m.E. (da auch unbelegt) einfach nicht korrekt. Gruß --Cvf-psDisk+/− 20:57, 19. Jun. 2014 (CEST)
thread_title:  Datenschutz?