Fragensteller
Newbefrage zu SQL, was können Sichten

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