Lord C schrieb:

bevor ich die Datenbank anhänge

Teste das in einem separaten Projekt mit einer lokalen Access-Tabelle.

Lord C schrieb:

aber bevor ich im dataset einen fehler mache

teste ich das ganze auf einer speziell für genau diesen und keinen anderen Test angelegten lokalen Datenbank.
Jou.

Die doppelte Beziehung zw. Team und Liga haut imo nicht hin.
Also entweder ein Team kann nur in einer Liga sein, dann ists eine 1:n-Relation, und die Relation mit der Zwischentabelle muss weg.
Oder ein Team kann in mehreren Ligen sein, dann ists eine m:n - Relation und die Relation Liga->Team muss weg.

Oder du hast dir dabei etwas besonderes gedacht, da würde ich dich dann drum bitten, das zu erklären.

Weiters fehlen Relationen zur Spiel-Entität, Team_1, Team_2 sind doch sicherlich Fremdschlüssel, oder?

Lord C schrieb:

eig war es gedacht das 1 team in einer liga sein kann aber eine Liga n teams haben kann.

Das ist eine 1:n - Relation, also kommt das mit der ZwischenTabelle weg

Lord C schrieb:

Zu team_1 usw ... Da wusste ich nicht genau wie ich es mache, das die relation eig zu team ist, aber immer 2 teams gegeneinader spielen

Einfach konsequent modellieren, auch wenns bisserl ungewöhnlich scheint:
Das sind 2 Fremdschlüssel, also zieh jeweils die Relation.
Mit dem Ergebnis, dass zwischen Team und Spiel 2 Relationen bestehen.
Das ist völlig korrekt, und Spiel ist die Mittler-Tabelle einer m:n - Relation von Team mit sich selbst.
Team -> Spiel <- Team Ja, ist so.

Lord C schrieb:

Zu team_1 usw dort sollen die spiele vermerkt weerden, die liga intern statt finden.

Ich verstehe nix vonne Ligen-Wissenschaften, aber könnte es sein, dass noch eine Relation auf Liga zu ziehen wäre?
Aber eigentlich auch nicht, also ich würde glaub nur die Teams mit den Spielen verknüpfen, und wenn ich Liga-Interne Spiele suche, dann gucke ich halt, ob die Teams eines Spiels in derselben Liga sind. (ähm - ist das nicht immer so?)

Jo, so scheint mir das plausibel.
Nur solltest du Public Properties mit Großbuchstaben anfangen lassen.
Das betrifft alle Tabellen und Tabellenspalten

Ja, und der Primärschlüssel einer jeden Tabelle kann einheitlich Id heißen - wenn du magst. Verwechslungen können trotzdem nicht auftreten, aber ist kürzer im Code, und v.a. man kann Primärschlüssel schon am Namen von Fremdschlüsseln unterscheiden.

Die Relationen sehen mir aus, als seine sie ohne Löschweitergabe und ForeignKeyConstraint angelegt.

Wäre hier aber bei glaub jeder Relation sinnvoll, zur Daten-Konsistenz-Sicherung. Und Löschweitergabe gewährleistet sowohl Datenkonsistenz als auch bessere Performance.

Das wird aber eh noch einigen Hirnschmalz kosten, son Dataset in jeder Hinsicht korrekt upzudaten.
Ich empfehle ja immer, DatasetOnly zu entwickeln, andere halten nicht so viel davon.
Ist jetzt vlt. eine gute Gelegenheit, mal einen das ausprobieren zu lassen - hihi.
Und vlt. irre ich mich ja auch, und nachträgliche Änderungen am Datenmodell sind auch mit mit-zupflegender Datenbank nicht gar so problematisch.
Meine Empfehlung ist ja, sich das nicht anzutun, wenn und solange man nicht muss.

k.A., was du mit Standard-Werten meinst, aber vergiss darüber nicht Löschweitergabe und ForeignKeyConstraint.

in Film1 bestimmt.
Das ist bei mir schon Reflex, Beim Einrichten einer Relation die beiden Checkboxen zu setzen.
Nachholen kannste das durch Doppelklick auf die Relation-Linie da.

Servus,

für mich ist ja quasi ein Paradebeispiel warum man eine Datenbank nehmen soll wenn man eine Datenbank will und nicht mit dem Dataset anfangen soll.

Bist du jetzt echt hingegangen und hast das Dataset nochmals händisch in einer DB angelegt? Warum?

Alle Werkzeuge und noch viel mehr hast du wenn du direkt in der DB anlegst. Das Dataset ist dann später nur für die Anwendung wichtig und das kann man auch sehr gut nachträglich ändern.

Datenbankdesign macht man auf der Datenbank!

Zudem scheint mir dein Vorhaben schon fast alleine mit den Datenbankmitteln realisierbar. Gespeicherte Prozeduren (in Access, glaube ich, Aufgaben) und Ansichten.

Dein Programm ist dann nur noch für das hübsche Anzeigen da.

Nachtrag: Wenn du alle Datenbanklogik an die Datenbank übergibst, kannst du auch schneller dein Frontend wechseln.
Zudem ist es so dass wenn du Ansichten verwendest du nur genau die Daten in dein Programm lädst die du gerade brauchst.

Jo, ich hätts auch ganz interessant gefunden, wenn er deinen Ansatz "Database-First" durchexerzieren würde.

Übrigens

MrTrebron schrieb:

Datenbankdesign macht man auf der Datenbank!

kann man glaub so pauschal nicht sagen - auch bei MS scheint man mit der Zeit drauf gekommen zu sein, den sog. "Model First"-Ansatz ebenfalls zu unterstützen:
Model First
versus
Database First

@ErfinderDesRades Model first ist auch interessant.
Es stellt aus meiner Sicht die Geschäftsobjekte in den Vordergrund.