MySQL - Filmdatenbank - Filmtitel/Darsteller Abfrage

[loddoking]

@meikel: Da sind wir von den Konzepten her wohl verschiedener Meinungen. Belassen wir es dabei!

Ich halte es zb für widersinnig und unübersichtlich Filme und Serien in einen Topf zu werfen. Ich hab dann zwar nur eine Tabelle. Aber dafür habe ich dann n dutzend Spalten drin die für die jeweils andere Kategorie völlig nutzlos und irrelevant sind und bestimmte abfragen nur unnötig komplizieren.
Vielleicht ist auch das Wort Kategorie falsch gewählt, das impliziert ein wenig dass es lediglich um verschiedene Genres ginge. Das tut es nicht. Es sind nicht ein/zwei spalten die sich unterscheiden, es sind rund ein dutzend.
Es sind, um beim Film/Serie Beispiel zu bleiben zwei völlig unterschiedlich paar Schuhe. Die bis auf die tatsache dass einige der Darsteller sowohl in Filmen als auch in Serien auftauchen nur ein paar gleichartige Spalten haben.

Ich mag es lieber wenn die verschiedenen Tabellen ordentlich getrennt für sich stehen. So hab ich das damals im Informatikunterricht auch vermittelt bekommen. Im übrigen habe ich mir ein paar andere mysql Filmdatenbanken angesehen die mit zum teil mehr als 20 Tabellen arbeiten.

Ich sage ja nur dass es zum gegenwärtigen Zeitpunkt, meiner Ansicht nach, keine gute Idee ist zu viel auf einmal zu wollen.
Solche zusammenlegungen sind sicherlich teilweise Sinnvoll. Ich werde auch nach und nach optimierungen durchführen.
Und wenn ich, im laufe meiner bemühungen, feststelle dass sich die eine oder andere Tabelle doch zusammelegen lässt, ist das auch kein Beinbruch und kann immer noch ohne zu großem Aufwand vollzogen werden.

Aber im Moment habe ich es ja nur mit der Film, Darsteller & Besetzungstabelle zu tun.

Und soweit es mich betrifft ist dieses Problem ja nun gelöst.
Neue werden sicherlich kommen und einige davon wären dann sicherlich mit fundierteren Kenntnissen vermeidbar gewesen. Also, nich böse sein. Einige Ratschläge wie mit der Besetzungstabelle habe ich ja nun angenommen. Andere hätte ich vielleicht annehmen sollen oder auch nicht. Hinterher werd ich vielleicht schlauer sein. Aber ist es so nicht immer? ;)

[meikel (†)]

Zitat von loddoking

@meikel: Da sind wir von den Konzepten her wohl verschiedener Meinungen. Belassen wir es dabei!

Mir ist das egal, welche Stolpersteine Du Dir in den Weg packst.

Hinterher werd ich vielleicht schlauer sein. Aber ist es so nicht immer? ;)

Na klar ist das immer so: jeder kleine Hosenscheißer verbrennt sich einmal im Leben die Pfoten am heißen Ofen.

[loddoking]

Zitat von meikel

Mir ist das egal, welche Stolpersteine Du Dir in den Weg packst.

Na klar ist das immer so: jeder kleine Hosenscheißer verbrennt sich einmal im Leben die Pfoten am heißen Ofen.

Ich werde an dieser Stelle hier jetzt mal nicht weiter darauf eingehen und habe dir diesbezüglich eine PM geschickt.

An alle anderen. Das eingangsproblem des Eröffnungsposts wurde von meiner Seite aus nun hinlänglich annehmbar gelöst und bedanke mich nochmals um die hilfreichen Hinweise.
Ich werde nun eine Weile brauchen um alles zufriedenstellend umzusetzen.
Diese Sache ist, an dieser Stelle, damit ja nun erledigt.

[sysop]

Nun, ich mische mich wider besseren Wissens doch nochmal ein.

Dein Datenbank Design aus dem ersten Post ist definitiv falsch, was dir bei deinem späteren Frontend wohl massiv auf den Kopf fallen wird.
Besser wäre, sich jetzt (am Anfang) einmal die Arbeit zu machen, alles in richtige Bahnen zu bringen, als dann später ständig zu hören, dass du deine DB erst mal normalisieren solltest.

Mein Vorschlag für die Tabellenanlage birgt Vorteile, die du noch garnicht wahrnehmen kannst und dir die spätere Erweiterung deiner Datenbank massiv erleichtert.
Ich kenn solche Projekte aus meiner eigenen Anfangszeit gut genug. Die Anforderungen wachsen, man will mehr und plötzlich steht man vor dem Aus, weil nichts mehr geht.

Bedenke bevor du deine Entscheidung entgülltig fällst, dass dein fehlerhaftes DB-Design sich in deinem gesamten Code nieder schlägt, weil du mit den zukünftigen Scripten alle DB-Design-Fehler korrigieren musst.

Viel Erfolg wünsche ich natürlich trotzdem.

[Ckaos]

Hi,

DB-Design sich in deinem gesamten Code nieder schlägt

Dann ist das ganze Code Konzept schon falsch ;)

MfG

CKaos

[sysop]

Zitat von sysop

...dass dein fehlerhaftes DB-Design sich in deinem gesamten Code nieder schlägt, ....

Sage ich ja auch.

[meikel (†)]

Zitat von sysop

Bedenke bevor du deine Entscheidung entgülltig fällst, dass dein fehlerhaftes DB-Design sich in deinem gesamten Code nieder schlägt, weil du mit den zukünftigen Scripten alle DB-Design-Fehler korrigieren musst.

Das will er nicht, weil er beratungsresistent ist. Dabei betrafen die Hinweise nur das DB Design. Anwendungssicherheit beim CSV Import u/o Formularrequest wären die nächsten Themen.

Egal... "Der Nächste bitte..."

[loddoking]

@meikel: Lass mal gut sein. Ich scheine hier nicht der einzige uneinsichtige beratungsresistente mensch zu sein!
Vielleicht stoßen in Zukunft deine hilfreichen Hinweise auf weniger auf taube Ohren wenn nicht jeder 2te Post eine persönliche Beleidigung enthält. Nimm dir ein Beispiel an die anderen hier. Das geht auch anders.
Und das ist mein letztes Wort in dieser Sache and dir!


An alle anderen:
Dem aufmerksamen Beobachter dürfte nicht entgangen sein dass ich schon längst einige der Vorschläge, so wie die von Sysop vorgeschlagene Besetzungstabelle aus zwei IDs, in meine Konzeptplanung übernommen habe.
Da sich das ganze Projekt derzeit immer noch in der Planungspahase befindet, dienen sämtliche Tabellen, Abfragen, Datenimporte und so weiter momentan lediglich dem experementieren, das mir unter anderem auch der Planung der nächsten Schritte dient.
Ob und wie sich die mir vorliegenden verschiedenartigen Datensätze sinnvoll in weniger Tabellen zusamenfassen lassen ist zum gegenwärtigen Zeitpunkt noch nicht ersichtlich.
Aber ich sagte ja bereits mehrmals das ich dies ebenfalls in meine Überlegungen mit einbeziehe.
Letztendlich handelt es sich aber bei dem ganzen aber immer noch um ein kleines, privates Hobbyprojekt dass nicht unbedingt professionellen Anforderungen gewachsen sein muss und ausschlißlich nur mir auf einem lokalen Webserver zur Verfügung stehen wird.

Ich kann, aufgrund meines begrenzten fachbezogenen Kenntnisstandes in dieser Angelegenheit leider nicht gleich ein voll funktionstüchtiges und optimiertes Konzept auf den Tisch legen und alle Eventualitäten bereits 20 Schritte im vorraus planen.
Vorschläge, die weit über den Rahmen der gestellten Fragen gehen, sind nicht immer zweckdienlich und verwirren nur allzu oft.
Und wenn ich nicht jeden Vorschlag sofort mit Kusshand und Verbeugung annehme, so ist das bei mir nie eine grundsätzliche Ablehnung desselben. Gut möglich dass es in weitere überlegungen mit einfliesst. Selbst wenn ich nicht sofort darauf eingehe.

Aber ich werde mich nicht beleidigen lassen und auch noch Danke sagen, nur weil ich in dieser Angelegenheit weniger Fachwissen aufzuweisen habe.
Nagut, solange derjenige nicht mein Gehaltsscheck zahlt! ;)

[Ckaos]

Hier,

alle Eventualitäten bereits 20 Schritte im vorraus planen

Sorry, auch wenn du das wieder als Angriff auslegst (meikel ist noch einer der lieben in der Forumwelt;) wenn du das nicht gewillt bist bei deinem "Hobbyprojekt" schon mit durch zu spielen dann lass es gleich DENN:
Wissen wir, die 50 Schritte vorplanen, meist was als nächstes kommt.
Bsp.:
- Wie bekomme ich diese Daten in die DB.... Achtung Hobby Projekt
- 1 Woche später
- Boah alles so langsam... Kunde ähhh Hobbyprojekt soll schneller laufen
- 1 Woche später
- Wie baue ich a,b,c und d jetzt ein (völlig unerwartet!)

Und das alles, maybe, mit 2 Doppelposts in uns bekannten "Deutschsprachigen" Foren,
weil ja Englisch soooo schwer ist!

Also reg dich nicht über Antworten auf sondern versuche zu verstehen oder auch zu hinterfragen warum wir was wann empfehlen.

MfG

CKaos

[loddoking]

Zitat von Ckaos

Hier,

Sorry, auch wenn du das wieder als Angriff auslegst (meikel ist noch einer der lieben in der Forumwelt;)

Ähmm...ok. Dann frag ich mal lieber nicht nach in was für Foren du sonst noch so verkehrst.;)

wenn du das nicht gewillt bist bei deinem "Hobbyprojekt" schon mit durch zu spielen dann lass es gleich DENN:
Wissen wir, die 50 Schritte vorplanen, meist was als nächstes kommt.
Bsp.:

Gewillt ja! Aber alles zu gegebener Zeit!

Ich versthe ja dass man als Fachkundiger so gut wie möglich helfen will. Jedoch schiesst man dabei gelegentlich, gerade bei unerfahrenen weit übers ziel hinaus.
Meiner Erfahrung nach ist es einfach am besten nur die Fragen zu behandeln die gestellt wurden. Natürlich treten dabei hinterher Probleme auf die man hätte von vornherein verhindern können und so manch einer zahlt dann eben etwas mehr Lehrgeld. Aber es ist nunmal für den Lernprozess unerlässlich fehler zu machen und machen zu dürfen.
Solange keine Finaziellen Interessen damit verbunden sind ist das alles doch nur halb so wild.
Ich trag es in solchen Fällen bestimmt niemandem nach wer er/sie mich wider besseren wissens ins offene Messer laufen lässt.
Gut, man kann es vielleicht kurz ansprechen. Aber dann eben gut sein lassen.

- Wie bekomme ich diese Daten in die DB.... Achtung Hobby Projekt
- 1 Woche später
- Boah alles so langsam... Kunde ähhh Hobbyprojekt soll schneller laufen
- 1 Woche später
- Wie baue ich a,b,c und d jetzt ein (völlig unerwartet!)

Öhmmm, ja. Solche fragen könnten schon auftauchen demnächst. Wenn ihr gewillt seid eins nach dem andern abzuhandeln.

Und das alles, maybe, mit 2 Doppelposts in uns bekannten "Deutschsprachigen" Foren,
weil ja Englisch soooo schwer ist!

Dollpelt hält besser. ;)
Schzuldig im Sinne der Anklage! Bei komplizierteren Sachverhalten bevorzuge ich eben die Sprache die ich am besten beherrsche. Wusste nicht dass man sich als Deutschsprachiger dafür entschuldigen muss...
Genaugenommen war es ja nur ein Doppelpost. Zwei Doppelposts würde ja bedeuten ich hätte die selbe Frage viermal gestellt. Hab es aber paar stunden vorher nur bei mysql.com reingestellt und erst hinterher auf selfphp.de gekommen und ich der meinung war dass dieses Forum die besse Alternative wäre. Leider liess sich der alte Post bei mysql.com nicht mehr löschen.

Also reg dich nicht über Antworten auf sondern versuche zu verstehen oder auch zu hinterfragen warum wir was wann empfehlen.

Ich reg mich lediglich über Antworten auf Fragen die ich zu dem Zeitpunkt gar nicht gestellt habe. Und keine Sorge, falls Fragen auftauchen sollten die ich nicht selbst lösen kann dann werd ich das auch zur Sprache bringen, genaugenommen kann ich dann sogar richtig penetrant beim nachfragen werden...

MfG