Community Projekt 1x03: "Datenbankentwurf"

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Community Projekt 1x03: "Datenbankentwurf"

    Hallo Mitglieder,

    ich habe einen ersten Datenbankentwurf erstellt. Ich würde mich über Feedback freuen. Natürlich sind noch nicht alle Features abgedeckt und nicht alle Strichte sind fertig gezogen ;)
    Für diejenigen die noch nicht in der Materie drinstecken, die sehen hier die Konzeption: trac.easy-coding.de/trac/contest/wiki/Konzeption

    Es wird viel mit Rollen gearbeitet:
    Gruppen können zum Beispiel Juroren, Sponsoren oder Teilnehmerteams sein.
    Threads sind Contests, Einladungen für Juroren, Sponoren, etc.
    Die einzelnen Beiträge sollen alle versioniert werden.

    Was die Datenbank so alles abdeckt
    • User können eine Aufgabe erstellen: post > thread(contest) > contest
    • Sie können Juroren einladen: post > thread(invitation) > groupaccess
    • Sie können einzelne Benutzer einladen: post > thread(invitation) > useraccess
    • Juroren können privat diskutieren ob sie teilnehmen sollten: post > thread
    • Und sie können Rücksprache mit dem dem Aufgabensteller halten: post > thread > useraccess
    • Mitglieder können Lösungen einsenden: post > thread > thread_contest
    • Mitglieder können den Contest nach unterschiedlichen Kriterien bewerten (threadrating)
    • Juroren können die Lösungen nach unterschiedlichen Kriterien bewerten (threadrating)
    • Nach dem Ende wird das Ranking gespeichert: post > thread > thread_contest(ranking)
    • Lösungen können kommentiert werden: post > thread
    • Benutzer können sich um Mitgliedschaft bewerben: group_application > thread
    • Gruppenmitglieder können die Bewerbung diskutieren: thread > post
    • Der Gruppenboss kann entscheiden user_group(usertype)
    • Neue Gruppen können gegründet werden
    • Neue Benutzer können angelegt werden
    • Die Versionshistorie von Lösungen und Beiträgen können gespeichert werden: post_diff
    • Anhänge können gespeichert werden: attachment
    • Sponsoren können Preise hinzufügen: contest_price
    • Wettbewerbe haben eine Start- und Endzeit
    • Sponsoren können bewertet werden: grouprating
    Bilder
    • db.png

      62,68 kB, 1.087×1.139, 694 mal angesehen
  • moin

    wow, ich muss sagen, da hast du wieder mal ganze arbeit geleistet :) *daumen hoch*
    da ich mich nicht mir dbs auskenne, kann ich jetzt nur was zu den funktionen sagen, und die sind soweit top.

    was mich jetzt so interessieren würde ist, wie du das bild erstellt hast? gibts da ne art script/ programm für, oder ist das mühsame handarbeit?
    und gibt es noch ne art guide, oder benutzeroberfläche für leute wie mich :p um die db zu nutzen? sry ich hab echt keien ahnung wie das läuft.

    mfg
    contest
    -- Ein Wettnewerb für Jugendliche Programmierer --
    Jeder Helfer ist willkommen ;)
  • ok danke, ich werd mir das mal alles runterladen und mich ein wenig damit auseinandersetzten.
    eine sache ist mir noch eingefallen, was man hinzufügen könnte:
    user sollten veto einlegen können, wobei für jede lösung nur max. ein veto geben sollte (sonst haben wir hinterher eine ganze flut ;))
    juroren sollten das veto diskutieren können.

    mfg
    contest
    -- Ein Wettnewerb für Jugendliche Programmierer --
    Jeder Helfer ist willkommen ;)
  • hab mal ne Frage zum DB-Schema:
    werden in "post_diff" nur die Unterschiede zur vorherigen Version gespeichert oder jeweils der komplette Post?
    Und was für ne Fremdschlüsselbeziehung hat denn "date" in "post"?
    Welche "group_id" und "user_id" wird in "Contest" gespeichert? Die des Erstellers? Warum dann User und Group id? Oder is das User_id vom ersteller und group_id von der Teilnahmeberechtigten Gruppe?
    Und für was ist "group_application" da?

    Fragen über Fragen ;D
  • Gute Fragen!

    Über das "wie" habe ich mir beim post_diff um ehrlich zu sein noch keine Gedanken gemacht. Bleibt zu diskutieren.
    date als Schlüssel war offensichtlich ein Fehler.

    Also wer den Contest erstellt hat - das wollte ich über contest > thread > post erschließen. Ich glaube zum besser joinen könnte man noch eine "firstPost" Spalte einfügen.
    Die eingesandten Lösungen sind selber Threads. Ich glaube das vereinfacht das Datenbankschema.
    n-eingesandte Lösungen will ich denn über die thread_contest Tabelle zum übergeordneten Contest zuordnen. Die Lösungen haben immer einen Benutzer als Veröffentlicher. Optional will ich dann mit der Spalte groupID ausdrücken, dass die Lösung von einer Gruppe stammen kann.

    Auch der Contest kann von einer Gruppe veranstaltet werden. Daher habe ich jetzt noch eine optionale Spalte "groupid" in contest eingeführt.

    Neu ist die post_claim Tabelle.
    Wenn ein Benutzer einen post meldet, dann erzeugt er einen neuen Thread und referenziert dazu einen vorhandenen Post.

    Neu eingeführt habe ich außerdem:
    Tabelle classes mit Beziehungen zu user (optional) und contest (zwingend).
    Vielleicht könnte man es auch karma nennen und einen Integer draus machen, der sich mit Erfahrung erhöht. Das könnte man aber auch in der Anwendung erledigen.
    Bilder
    • db.png

      66,46 kB, 1.087×1.099, 471 mal angesehen
  • hiho

    also ich hätte da mal ne frage zu der db:
    Sie können Juroren einladen: post > thread(invitation) > groupaccess

    wie stellst du dir das vor? können sie dann aus einer liste oder so einen juror zu der gestellten aufgabe einladen, oder wie muss ich das verstehen?

    und hier noch etwas, was man ergänzen könnte. vllt gar nicht mal unwichtig.
    man sollte die möglichkeit bekommen, ein feedback zum contest als ganzen abgeben zu können. also nicht für einen einzelnen wettbewerb, sondern auch für organisation, jury, usw.

    mfg
    contest
    -- Ein Wettnewerb für Jugendliche Programmierer --
    Jeder Helfer ist willkommen ;)
  • Hi,
    ja genau,,, entweder man wählt aus der Liste ein Jurorenteam - oder per Default wird das "Admin"-Jurorenteam verwendet.
    Was das Feedback angeht - so deckt die Datenbankbank (mit threadrating) hoffentlich alles ab - aber konkrete Stellen zum einbauen habe ich in den Usecases noch nicht vorgesehen.
    Man sollte sie aber definitv bedenken!