dabadepdu
Datenbank-Guru
- Beiträge
- 1.860
Das verstehe ich jetzt nicht. Wieso beschäftigst Du Dich nicht mit der Syntax? Bzw. was verstehst Du unter Syntax?Ich verstehe das inhaltlich! mitd er Syntax habe ich mich nicht beschäftigt,
Folge dem Video um zu sehen, wie unsere Website als Web-App auf dem Startbildschirm installiert werden kann.
Anmerkung: Diese Funktion ist in einigen Browsern möglicherweise nicht verfügbar.
Das verstehe ich jetzt nicht. Wieso beschäftigst Du Dich nicht mit der Syntax? Bzw. was verstehst Du unter Syntax?Ich verstehe das inhaltlich! mitd er Syntax habe ich mich nicht beschäftigt,
SQL Server 2017I
Komplett? Dann habe ich etwas übersehen, Table Create oder Daten sind mir nicht aufgefallen.
Die Online Plattform ist nur ein Beispiel, das ist Luxus. Du kannst Create Script, Insert Statements, Select Statements, falsche Ergebnisse, Fehlermeldungen alle einfach hier reinkopieren, als Text.
Doch, "SQL Server" ist eine gängige Bezeichnung / "Abkürzung" für Microsoft SQL Server. Er wird auf dieser Online Plattform sogar für viele verschiedene Versionen angeboten. Vermutlich ist er (der Hersteller spezifische Server) für die Probleme, die Du hast noch nicht mal entscheidenend. Weil Deine Probleme sehr grundlegender Natur sind und auf jedem Server gleichermaßen auftreten.
Ich habe noch nicht mit foreign keys gearbeitet und weiß auch nicht, inwieweit die benötigt werden.Super!
In dem ersten Abschnitt (Tabellenerzeugung) gibt es keine Foreign Key Constraints. Ich weiß nicht, ob das dem Original entspricht oder ein "Übertragunsfehler" ist.
Annahme anhand der Bezeichnung:
Alle "Nummer" Spalten beziehen sich auf "Aufträge.Nummer".
Dann ergibt sich bei Deinem Beispiel Select in der Where Condition ".. AND B.Nr = W.Item " die Frage:
Warum ist Nummer überall ein Fremdschlüssel (reine Annahme, aber wirkt plausibel) und warum sollte dann die Spalte ITEM in WARENBUCHUNG ebenfalls ein Fremdschlüssel zu Nummer sein oder in sonst irgendeiner sinnvollen Beziehung dazu stehen, die diese Filterung in der Where Condition rechtfertigt?
Mmh, also ich glaube schon, dass Du mit sowas gearbeitet hast, mglw. ohne es zu wissen. Du hast es lediglich implizit genutzt.Ich habe noch nicht mit foreign keys gearbeitet und weiß auch nicht, inwieweit die benötigt werden.
select a.nummer,w.item,w.split
from aufträge as a
left join warenbuchung as w on a.nummer = w.nummer
left join beanstandungen as b on a.nummer = b.nummer and b.nr = w.item
where a.nummer ='1' ;
Das ist nur geraten! Du oder jemand, der Dein Projekt kennt, sollte das genau wissen. Im Normalfall gehört sowas in das Datenmodell als explizite FK Definition.Wenn es so wäre, wie ich hier vermute
So scheint es ja zu funktionieren. Danke für die Hilfe. Schlüssel habe ich aber tatsächlich noch nie definiert und nur über die Joins gearbeitet. Ich bin immer davon ausgegangen, dass die Nummer, da in allen tabellen vorhanden der Schlüssel ist.Mmh, also ich glaube schon, dass Du mit sowas gearbeitet hast, mglw. ohne es zu wissen. Du hast es lediglich implizit genutzt.
Die explizite Angabe von Foreign Keys ist ja nichts anderes als dem Server zu verraten, welche Spalte einer Tabelle sich auf eine andere Spalte in einer (anderen) Tabelle bezieht. Der Server weiß also was wie zusammengehört und kann die korrekte Wertebefüllung überwachen.
In Deinem Fall scheint es mir so zu sein, dass weder der Server noch Du so Recht wissen, welche Spalten zusammen gehören. Kannst Du im Original nachschauen, welche Foreign Key Constraints definiert sind?
Wenn es so wäre, wie ich hier vermute, dann gibt es -ähnlich zu Deiner Idee- keine duplizierten Einträge:
Code:select a.nummer,w.item,w.split from aufträge as a left join warenbuchung as w on a.nummer = w.nummer left join beanstandungen as b on a.nummer = b.nummer and b.nr = w.item where a.nummer ='1' ;
Also das glaub ich nicht, idR definiert man vor allem Primär Schlüssel. Es ist denkbar, dass Du nur an "fertigen" Tabellen arbeitest, die jemand anders "entwirft", die vielleicht sogar von einer Persistenz Engine "entworfen". So oder so, es gibt diese Schlüssel, man nützt sie logisch sowieso. Und wie Dein Beispiel zeigt auch nicht unbedingt nur einen pro Abfrage.So scheint es ja zu funktionieren. Danke für die Hilfe. Schlüssel habe ich aber tatsächlich noch nie definiert und nur über die Joins gearbeitet. Ich bin immer davon ausgegangen, dass die Nummer, da in allen tabellen vorhanden der Schlüssel ist.
Ja, ist sie auch, vermutlich- Du hast es im Create Statement nicht definiert- man ahnt es nur durch den Spaltennamen.Ich bin immer davon ausgegangen, dass die Nummer, da in allen tabellen vorhanden der Schlüssel ist.
Schau Dir noch mal mein Beispiel an, da sind sie definiert. Foreign keys und Primary Keys, erstere funktionieren nicht ohne letztere.Ich habe noch nicht mit foreign keys gearbeitet und weiß auch nicht, inwieweit die benötigt werden.
Das verstehe ich, ich wusste bis vorher nur nicht, dass es eine Onlineseite gibt, bei der ich Beispieltabellen erstellen kann, somit waren die Screenshots gedanklich für mich der einzige logische Weg mein Problem darzustellen. Danke für die Info.Ich hoffe, Du verstehst auch langsam, warum Screenshots nicht besonders hilfreich sind, zu einer Lösung zu kommen.
Ich erstelle keine Tabellen, sondern lese nur Daten aus, dementsprechend -wenn es sowas gibt- hat es jemand anders erstellt. Ich habe mir nur alle tabellen angeguckt bund geguckt wie ich die verknüpfen kann. Ist das definieren des Schlüssels denn notwendig? Es scheint ja auch ohne zu funktionieren."fertigen" Tabellen arbeitest, die jemand anders "entwirft", die vielleicht sogar von einer Persistenz Engine "entworfen".
Inwiefern?Das hätte nicht nur enorme funktionale Vorteile für die DB
Das hätte nicht nur enorme funktionale Vorteile
Inwiefern?
Vielen Dank für die vielen Infos und hilfreichen Tipps, ich werde mich damit bei Zeiten genauer beschäftigen!DBFiddle und ähnliche Seiten sind toll, aber wie gesagt nur eine Luxusvariante davon, was ich Dir nahegelegt habe bzw. was in einem Programmierforum Standard ist:
Einfach die "Texte", also Code, den Du bei DBFiddle eingetragen hast, hier im Forum posten, das reicht. Bei Datenbankfragen beinhaltet der Code das Datenmodell, also Tabellen Definitionsskripte, Trigger-wenn vorhanden, Daten, also Insertskripte und die eigentlichen Abfragen.
Allein das Lesen der (vollständigen) Tabellendefinition hilft (den Helfern). Es würde bspw. alle Schlüsselfelder zeigen, ohne dass man ein einziges Wort darüber verlieren müsste.
Wenn Du selbst Dir Tabellen anguckst, um festzustellen, wie Du sie verknüpfen könntest, machst Du das scheinbar anhand der Spaltennamen. Das ist dann Glückssache, ob es klappt und ausreicht.
Wie gesagt, das Createskript der Tabelle enthält eigentlich diese Angaben explizit, wenn es ordentlich gemacht ist. Du musst dann nicht verstehen oder raten oder die Sprache kennen, in der die Spalte benannt wurde. Wenn Du gemäß Deines Jobs nur Abfragen bauen musst, kann es leider sein, dass du nicht mal das Recht hast, diese Infos über das Datenmodell in deiner IDE abzulesen. Und IDE können das natürlich darstellen, sofern es jemand definiert und freigegeben hat. (In diesem Fall sollte man diese Informationen allerdings auf anderem Weg zur Verfügung gestellt bekommen.)
Und nein, das Definieren von Schlüsseln oder Fremdschlüsseln ist nicht notwendig. Das ist ja das "Gefährliche", Bequeme, Blöde!
Ich kenne Systeme (käuflich), die diese Informationen extra nicht in der DB angeben, weil sie es geheim halten wollen. Sie wollen nicht von Dritten kopiert, gelesen, verstanden oder weiterverarbeitet werden.
Kann man so machen, hindert einen Neugierigen am Ende auch nicht, die Schlüsselfelder rauszufinden, hindert einen Böswilligen dann ebensowenig, Daten zu manipulieren.
Ich hab jetzt keine Lust eine Hausarbeit über Datenmodellierung und ihren Sinn zu schreiben.
Vielleicht mal so: Es gibt sehr viele Dinge in einem modernen RDBMS, die man nicht machen muss, aber machen kann. Man verschenkt große Teile ihrer Haupteinsatzgründe, wenn man es nicht tut.
Je mehr dieser Features man nicht nutzt, desto mehr nähert man sich von der Arbeitsweise an die Nutzung eines Editors an oder eines Excel Sheets an.
Man kann CSV nehmen statt ein vollwertiges RDBMS. Man kann sogar noch auf feste Spalten verzichten. Häufig reicht das vielleicht.
Eine DB ist nicht nur eine Sammlung von Datensätzen. Sie ist vor allem auch eine Sammlung von Regeln und Strukturen (Datenmodell).
Der Hammer: Ein Datenbankserver garantiert(!) die Einhaltung aller definierten Regeln. Klingt vielleicht banal, ist aber enorm.
Und es liegt auf der Hand: wenn ich keine Regeln (z.B. Foreign Keys) definiere, kann der Server auch solche Regeln nicht überwachen, geschweige denn einhalten.
In dem Zusammenhang spannend zum Verständnis:
Welche Unterschiede gibt es da zwischen RDBMS und noSQL Systemen?
Oder nicht ganz so krass, "Was passiert eigentlich, wenn mein Persistenzsystem nicht versteht, welche Klassen ich definiere?" (oder wenn ich nicht verstehe, was das Persistenzsystem daraus macht / was es eigentlich kann?)
Du kannst auch mal folgendes überlegen:
- wie ist auf Dauer meine Datenqualität in einem System, bei dem ich allein die DB und das zugreifende Programm schreibe
- wie ändert sich das mit mehreren Programmierern
- wie ändert sich das mit mehreren Programmen (und mehreren Programmierern)
Wie kannst Du die Antworten darauf systematisch (und positiv) beeinflussen?
Eine Datenbank kann für eine gute Datenqualität sorgen, sie hält garantiert alle definierten Regeln ein. Ein Stichwort in dem Zusammenhang noch: ACID; kannst Du mal im Internet nachlesen. Da steht sowieso viel mehr und Besseres, als ich hier schreiben kann.