none
Newbefrage zu SQL, was können Sichten RRS feed

  • Frage

  • Hallo Forum,

    bevor ich in SQL-Server einsteige habe ich einige grundlegende Fragen über die Funktionsfähigkeit von SQL.

    Folgendes Szenarion:

    Kaufmännische Datenbank SQL, technische Datenbank Access oder SQL (vorzugsweise SQL).

    Beide Datenbanken verwenden eine Artikelnummer als PrimID.

    Beide Datenbanken werden von Frontends bedient, auf die ich leider keinen Einfluss habe. Was wiederum bedeutet, dass natürlich die Feldbezeichnungen sowie die Tabellennamen unterschiedlich sind.

    Mein Wunsch ist es ein Sicht auf die kaufm. Datenbank zu erstellen, die vom technik-Frontend als bekannt gesehen wird. Hier muss dann im Grunde die ID-Spalte in die Techniktabelle verknüpft werden, sodass ich vom Technikfrontend auf ein paar Spalten der kaufm. Tabelle zugreifen kann (Artikelbeschreibung z.B.).
    Ich stelle mir das so vor:
    Tabelle "kaufmParts", Spalte "Artikelnummer" existiert (ID), Spalte Bezeichnung existiert.
    Tabelle "technikParts", Spalte "Bestellnummer" existiert (ID), Spalte Artikelbeschreibung existiert.

    Das Technikfrontend greift auf die Tabelle "technikParts" zu.
    Diese wird nun umbenannt und in eine Sicht, die dann auch "technikParts" genannt wird (oder Abfrage oder was auch immer) eingebunden.
    Hier stelle ich mir vor, als Beispiel eine Spalte Bezeichnung der originalen "technikParts" durch eine verknüpfte Spalte (z.B. "Artikelbeschreibung") der "kaufmParts" zu ersetzen. Hier muss natürlich der Spaltenname einen Alias Namen bekommen ("Bezeichnung").
    Das Frontend würde nun statt der Tabelle die Sicht sehen und könnte auf die Daten zugreifen.
    Geht sowas lesend und schreibend?

     

    Danke Carsten

    Mittwoch, 3. August 2011 16:39

Alle Antworten

  • Nochmal zur Erläuterung, so könnte eine Abfrage aussehen, die das können müsste.
    Nur bin ich grade nicht sicher ob die RW ist.

    SELECT kaufmParts.Artikelnummer, kaufmParts.Bezeichnung AS Artikelbeschreibung
    FROM technikParts INNER JOIN kaufmParts ON technikParts.Bestellnummer = kaufmParts.Artikelnummer;

    Oder bin ich mit Sichten total aufm Holzweg?
    Brauch ich nur ne einfache Abfrage?

     

    Danke Gruß Carsten

    Mittwoch, 3. August 2011 17:07
  • Hallo Carsten,

    nur unter bestimmten Umständen können die zugrundeliegenden Tabellen einer View (Sicht) über die View aktualisiert werden und auch dann können nur die Daten einer Tabelle geändert werden; nie die Daten von mehr als einer Tabelle. Siehe MSDN Create View => Aktualisierbare Sichten.

    Andere Option ist auf dem View INSTEAD OF Trigger anzulegen, die DML Aktionen abfangen und die Insert/Update/Delete Logiken selbst abbilden.


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Mittwoch, 3. August 2011 17:39
  • Hallo Olaf, erst mal vielen Dank für Deine Antwort. Also gut, wenn die Sichten das nicht selber können, gibt es einen anderen Weg? Vielleicht ordinäre Abfragen? Ich weiß, es klingt jetzt etwas unprofessionell aber mir fehlt bei SQL Server einfach die Erfahrung. Wo müsste ich denn den Trigger hin programmieren. Mein Problem liegt bei dieser Aktion darin dass ich weder auf das Technik- noch auf das kaufmännische Addin Einfluss habe. Wird das dann ein Dienst der aufm Server lauscht ob was passiert? Oder wie stelle ich mir das vor? Gruss Carsten
    Mittwoch, 3. August 2011 19:12
  • Mit Abfragen geht das gar nicht. Diese sind ja im Prinzip ad hoc.

    Es bleibt nur die Sicht. In dieser erstellst Du dann den Instead Of-Trigger.

    Es handelt sich auch nicht auf einen Dienst, der auf den SQL Server lauscht, sondern Du erstellst die Sicht in dem SQL Server, anstelle der Tabelle (die mußt Du umbenennen, wie Du eingangs ja schon beschrieben hast).

    Was Du auch brauchst: im SQL Server einen Verbindungsserver zur Access-Datenbank. Alternativ die benötigten Tabellen und/oder Sichten  des SQL Server im Access eingebunden, ansonsten kannst Du nicht gleichzeitig auf Tabellen beider Datenbanken zugreifen.

    Mittwoch, 3. August 2011 20:42
  • Hallo Christa,

    danke für Deine Antwort.

    Ich hatte geplant die Tabellen der trechnik-Datenbank dann mindestens auf den SQL-Server zu packen oder vielleicht sogar mit in die kaufm. Datenbank.

    Das sollte also kein Problem darstellen.

    Bei dem Thema Trigger werde ich mir nochmal etwas Lektüre antun. Ich brauchte eben nur nen Hinweis, wo ich anfangen soll mit dem Raten :D

    Danke Dir für den Hinweis auf den Trigger in der Sicht.

     

    Gruß Carsten

    Mittwoch, 3. August 2011 21:09
  • Hallo Telefisch

    Aus Deiner Beschreibung geht nicht genau hervor, was Du mit der PrimID in der View machen willst und ob diese View einen JOIN enthält und ob da auch geschrieben werden soll. Auch ist ist mir nicht klar, wie die PrimID definiert ist (Identity oder vom Programm vergeben).

    Die einfachste Möglichkeit, die Antwort so zu erhalten, wie Du diese haben willst, ist, das ganze halt mal in einem SQL Server (Express) auszuprobieren. Das kannst Du sicher viel schneller bewerkstelligen, als uns hier alles bis in die kleinsten Details zu erläutern.

    Gruss
    Henry
     Telefisch wrote:

    Beide Datenbanken verwenden eine Artikelnummer als PrimID.

    Beide Datenbanken werden von Frontends bedient, auf die ich leider keinen
    Einfluss habe. Was wiederum bedeutet, dass natürlich die
    Feldbezeichnungen sowie die Tabellennamen unterschiedlich sind.

    Mein Wunsch ist es ein Sicht auf die kaufm. Datenbank zu erstellen, die
    vom technik-Frontend als bekannt gesehen wird. Hier muss dann im Grunde
    die ID-Spalte in die Techniktabelle verknüpft werden, sodass ich vom
    Technikfrontend auf ein paar Spalten der kaufm. Tabelle zugreifen kann
    (Artikelbeschreibung z.B.). Ich stelle mir das so vor:
    Tabelle "kaufmParts", Spalte "Artikelnummer" existiert (ID), Spalte
    Bezeichnung existiert.
    Tabelle "technikParts", Spalte "Bestellnummer" existiert (ID), Spalte
    Artikelbeschreibung existiert.

    Das Technikfrontend greift auf die Tabelle "technikParts" zu.
    Diese wird nun umbenannt und in eine Sicht, die dann auch "technikParts"
    genannt wird (oder Abfrage oder was auch immer) eingebunden.
    Hier stelle ich mir vor, als Beispiel eine Spalte Bezeichnung der
    originalen "technikParts" durch eine verknüpfte Spalte (z.B.
    "Artikelbeschreibung") der "kaufmParts" zu ersetzen. Hier muss natürlich
    der Spaltenname einen Alias Namen bekommen ("Bezeichnung").
    Das Frontend würde nun statt der Tabelle die Sicht sehen und könnte auf
    die Daten zugreifen.
    Geht sowas lesend und schreibend?



    Danke Carsten

    Donnerstag, 4. August 2011 10:25
  • Hallo Telefisch

    Telefisch wrote:

    Nochmal zur Erläuterung, so könnte eine Abfrage aussehen, die das können
    müsste.
    Nur bin ich grade nicht sicher ob die RW ist.

    SELECT kaufmParts.Artikelnummer, kaufmParts.Bezeichnung AS
    Artikelbeschreibung
    FROM technikParts INNER JOIN kaufmParts ON technikParts.Bestellnummer =
    kaufmParts.Artikelnummer;

    Oder bin ich mit Sichten total aufm Holzweg?
    Brauch ich nur ne einfache Abfrage?

    Wie sollen wir das wissen? Obige Abfrage ist ReadOnly (auch wenn sie in einer Sicht steckt), das ist Dir bewusst, gell?

    Gruss
    Henry

    Donnerstag, 4. August 2011 10:26
  • Danke Dir für den Hinweis auf den Trigger in der Sicht.

    Hallo Carsten,

    Trigger sind nicht in der Sicht, eher "auf" der Sicht.

    Beispiel für ein View mit Instead Of Trigger: http://olafhelper.over-blog.de/article-inserts-abfangen-und-umleiten-37229366.html

     


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Donnerstag, 4. August 2011 16:19
  • Tja Henry, wenn Du nichts bei zu tragen hast ausser "probier's selber" dann spar Dir doch einfach Deine Kommentare.
    Dazu sind Foren i.d.R. da und mich kotzt es ehrlich gesagt langsam an, dass in jedem Forum einer existiert, der nur den angehenden Profis antwortet und sich von Anfängern belästigt fühlt.
    Also vielen Dank für Deine Hinweise, ich habs verstanden und es ist mir egal.

    So und nun zum Thema zurück...

    Olaf, Dein Blog trifft ja nahezu auf den Punkt mein Problem :)
    Bevor ich jetzt aber anfange diverse Software zu installieren vielleicht ein kleiner Hinweis, wo man das hinprogrammiert?
    Das ist nämlich der Punkt der mich im Moment vom Testen abhält.
    Zuerst hatte ich gedacht ich muss ne exe oder ne dll erstellen und die aufm Server laufen und "lauschen" lassen. Dann hatte ich es so verstanden dass ich aufm SQL-Server direkt programmieren kann.

    Hmm... bitte nicht lachen, ist mir auch irgendwie peinlich aber um es mal einfach aus zu drücken, ich hab keine Ahnung wo ich das hinschreiben soll :( Danke Carsten

    Freitag, 5. August 2011 06:03
  • Hallo!
    Du solltest Dir den entsprechenden Client für den SQL Server installieren und Dich dann mit dem Management Studio verbinden. Dort kannst Du dann entweder über GUI oder per SQL die notwendigen Objekte sehen, anlegen und ändern.
     
    Falls Du keinen SQL Server laufen hast, wären aber wirklich wie von Henry empfohlen erste Schritte auf einer lokalen Express Installation mit Tools zu machen:
     
    Alternativ besorg Dir eine Developer Lizenz für einen PC.
     
    Einen schönen Tag noch,
    Christoph

    Microsoft SQL Server MVP
    www.insidesql.org/blogs/cmu
    Freitag, 5. August 2011 09:59
  • Hallo Christoph,

    danke für Deine Antwort.

    Ich will es ja selber herausfinden, grade weil man es so am besten lernt...
    An einen SQL-Server komme ich drann. Da hatte ich über Visual Studio schon des öfteren Kontakt aber eher rudimentär als reine Datenquelle.

    Ich werde mir das mit dem Managemant Studio anschauen. Das sollte dann fürs Erste an Lesestoff reichen ;)

    Wenn noch was fehlt melde ich mich nochmal.

    Also danke nochmal

    Gruss Carsten

    Freitag, 5. August 2011 10:36
  • Telefisch wrote:

    Ich will es ja selber herausfinden, grade weil man es so am besten
    lernt...

    ... Nun kann ich mir das Lachen nicht mehr unterdrücken ...

    Gruss
    Henry

    Montag, 8. August 2011 04:35
  • Ja genau...

    dann solltest Du nochmal lesen und gut ist!

    Und spar Dir doch einfach Deine Kommentare!!!!

    Montag, 8. August 2011 21:06
  • Hallo!
    Dieser Umgangston erhöht aber nicht gerade die Chance auf konstruktive Antworten, oder?
     
    Ich denke, Du tust Henry da unrecht, zumal er ein sehr kompetenter Entwickler ist, der schon vielen Leuten weitergeholfen hat.
     
     
    Einen schönen Tag noch,
    Christoph

    Microsoft SQL Server MVP
    www.insidesql.org/blogs/cmu
    Dienstag, 9. August 2011 08:28
  • Hallo Christoph

    Vielleicht hätte ich meine erste Antwort besser erläutern sollen. Aber da er lernen wollte, habe ich ihm empfohlen, es selber auszuprobieren, was ja ziemlich einfach ist.

    Ich gehe davon aus, dass er hat eine Access Frontend hat. Access beinhaltet die Möglichkeit, dass man dort Abfragen über zwei Tabellen fahren kann, deren Daten durchaus änderbar sind. Es macht daher IMNSHO keinen Sinn, hier auf dem SQL Server Views anzulegen, welche das nicht können und dann diese Möglichkeit mit Instead Of Triggern nachzubilden. Allerdings bedingt dieses Feature, dass der Primär- und Fremdschlüssel in der Query enthalten sind. Access wird dann automatisch zuerst den Primär-Tabellen Datensatz hinzufügen und anschliessend den erhaltenen Schlüssel in der Child Tabelle als Fremdschlüssel verwenden, wenn es diesen Datensatz einfügt. Details findet man in der OH von Access unter den Begriffen "änderbare Abfragen". Darum war meine Frage in der ersten Antwort, dass er ein bisschen mehr über die Tabellenstruktur, rsp. die PrimID preisgeben sollte, um für eine bessere Antwort entscheiden zu können, ob Access damit umgehen kann oder nicht.
    Daher auch der Hinweis im zweiten Posting, dass er das am einfachsten auf dem SQL Server ausprobiert, da er dann selber sieht, ob es geht oder nicht und anschliessend nachfragen könnte, wie er das, was er konkret machen will, doch hinbekommen könnte.

    Ich selber bin der Meinung, dass es übersichtlicher und einfacher ist, wenn man eine Access Frontend verwendet, die Tabellen 1:1 einzubinden und Sichten nur für Readonly Abfragen zu benutzen, wenn man die Performance sicherstellen muss. Wenn die Benutzer in den Tabllen, welche auf Sichten aufbauen, direkt Daten bearbeiten, dann ist das eine relativ schlechte Programmierung (und wird z.B. bei www.mvps.org/access als eine der 10 Sünden von Access aufgeführt). Der Benutzer sollte nicht direkt in Tabellen (auch wenn diese auf Views aufbauen) Hand anlegen, sondern die dafür vorgesehenen Formulare benutzen, welche der Frontend Ersteller bereitgestellt hat.

    Nun gut, das nächste Mal werde ich wieder ein bisschen ausführlicher schreiben, wir wollen hier ja keine Trolle züchten.

    Gruss ins kriesengeschüttelte Europa

    Henry

    Dienstag, 9. August 2011 09:58
  • Hallo Henry,
    vielen Dank für Deine ausführlichen Erläuterungen!
    Hier wird man derzeit nicht nur krisengeschüttelt, sondern auch noch trotz Sommer ziemlich nass. Das dürfte bei Dir zumindest besser sein!
     
    Einen schönen Tag noch,
    Christoph

    Microsoft SQL Server MVP
    www.insidesql.org/blogs/cmu
    Dienstag, 9. August 2011 10:21
  • Hallo!
    Dieser Umgangston erhöht aber nicht gerade die Chance auf konstruktive Antworten, oder?
     
    Ich denke, Du tust Henry da unrecht, zumal er ein sehr kompetenter Entwickler ist, der schon vielen Leuten weitergeholfen hat.
     
     
    Einen schönen Tag noch,
    Christoph

    Microsoft SQL Server MVP
    www.insidesql.org/blogs/cmu

    Hallo Christoph, bis zu Deiner bzw. zu Henrys nächster Antwort war leider von konstruktiv rein gar nichts zu sehen.

    Nur weil ich keine Ahnung hab von SQL-Server bin ich kein dummer Junge und meine Frage war möglichst klar gestellt.

    Offensichtlich gab es ja andere User, die zumindest versucht haben mir zu helfen.

     

    Carsten
    Dienstag, 9. August 2011 20:43
  • Zu Deiner Antwort Henry...
    vielen Dank dafür, so ausführlich hätte ich es nicht gebraucht.

    Wie ich oben als erstes geschrieben hatte wollte ich wissen ob es einen Lösungsansatz für mein Problem gibt, bevor ich tagelang SQL-Server lerne um dann zu sehen dass es eh nicht das kann, was ich brauche.
    Ich brauchte sozusagen einen Türöffner.

    Deine Antwort ist wirklich sehr ausführlich und war von mir so gar nicht erwartet worden.
    Ich weiß, dass Profis den Anfängern nicht ihre Hausaufgaben machen wollen und sollen aber den Startschuss, einen Link oder nen Hinweis ist da schon manchmal zielführend.

    Ich habe kein Access FE.
    Das wäre ja schön einfach. Da hätte ich zur Not was bei programmiert.
    Eine Abfrage habe ich zum generellen Test in Access aufgebaut und das Editieren der Daten ging auf jeden Fall damit. So war für mich klar, dass es einen Weg geben muss und dass das FE damit umgehen kann.

    Also Ziel ist es die ganze Geschichte in SQL abzubilden und das sollte so auch klappen.

    Ich danke DIr also für Deine sehr ausführliche Antwort... ich will ja kein Troll sein

     

    Viele Grüße

    Carsten

    Dienstag, 9. August 2011 20:44
  • Hallo Carsten,
    nachdem nun alle Fragen geklärt sind, hoffen wir auf viele weitere spannende Fragen und Antworten.
    Hierbei darf man aber nicht vergessen, dass alle hier anwesenden dies unentgeltlich machen.
    Alle Beteiligten gewinnen aber durch die Beschäftigung mit solchen Fragen!
     
     
    Einen schönen Tag noch,
    Christoph

    Microsoft SQL Server MVP
    www.insidesql.org/blogs/cmu
    Mittwoch, 10. August 2011 06:55
  • Hallo Carsten,

    mal anderes gefragt; muss die Datenaktualisierung unbedingt über eine View laufen? Die sind eigentlich nicht wirklich dafür vorgesehen. Im alten Enterprise Manager konnte man Daten aus Views auch bearbeiten, das war aber eher ein Bug als ein gewollte Feature und deswegen geht es in SSMS nicht mehr; dort kann man auch nur Daten aus einer Tabelle von einer Sicht ändern.

    Klassischer Weise verwendet man eher Stored Procedures um umfangreicher Aktionen durchzuführen und auch um Business Logic zu implementieren. Vielleicht wäre das für Dich & diesen Fall die bessere Lösung.  


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Donnerstag, 11. August 2011 16:20
  • Hmm...

    also im Grunde habe ich "nur" das Problem dass die beiden Frontends, die ich selber leider nicht umprogrammieren kann sich eine gemeinsame Datenbasis teilen sollen.

    Es sind einige Felder, die redundant wären, was man natürlich vermeiden sollte.

    Deswegen war meine Idee für die Technik-Software eine quasi virtuelle "eigene" Datenbank zur Verfügung zu stellen.

    Dazu muss ich einen großen Teil der originalen Tabellen einbinden, was ja gar kein Problem darstellt.

    Ein paar Daten kommen aber aus der kaufm. Datenbank.

    Da ist z.B. die Bestellnummer ein identifizierendes Feld, dass ähnlich einer ID im technischen FE verwendet wird.

    Dann sollen noch Felder wie Bezeichnung, Typennummer, Artikelnummer etc. in beiden FEs zur Verfügung stehen.

    Es wäre denkbar, neue Artikel nur auf einer Seite an zu legen (in der kaufm. FE z.B.) und von beiden Seiten nur ändern zu können.

    Mein Kunde will den Part der Datenbankanpassung einem für das kaufm. FE zertifizierten Dienstleister übergeben.

    Bin ich nicht grade böse drum ;) ich muss dem nur sagen wie er das angehen soll bzw. was er zu tun hat :(

    Ich programmier dann später lieber wieder Oberfläche und Objektorientierte Projektdatenbanken im technischen System.

     

    Also wenn es für diesen Fall was besseres gibt...

    Nur wie gesagt ich kann in die beiden FE's nicht eingreifen.

     

    Danke und Gruß

    Carsten

    Donnerstag, 11. August 2011 19:08