nicht angemeldet
DB für Unterricht entwickelt -> Tester gesucht
Hallo zusammen,
nachdem ich in den letzten Tagen so manches gefragt habe, dachte ich, dass es nur fair ist, wenn ihr auch das Resultat seht.
Ich habe für meinen Informatik-Unterricht eine DB gebraucht. Und da wir nur Access haben (und die auch nur so lala läuft), habe ich angefangen eine eigene DB zu schreiben.
Jetzt bräuchte ich mal eure Meinung vorneweg. Schreibt doch ob ihr meint, dass man damit die absoluten Grundlagen von DB unterrichten kann und vielleicht auch, wie die Programmierung/Design/CSS ist.
Um es gleich vorneweg zu nehmen: Manche eurer Vorschläge konnte ich aus Zeitgründen noch nicht einbauen.
Aber es sollten dennoch alle grundlegenden Funktionen funktionieren.
-
Hi,
Ich habe für meinen Informatik-Unterricht eine DB gebraucht. Und da wir nur Access haben (und die auch nur so lala läuft)
Das ist systemimmanent bei Access.
habe ich angefangen eine eigene DB zu schreiben.
Ein heubsche Uebung -- vor allem in Javascript ;-)
Jetzt bräuchte ich mal eure Meinung vorneweg. Schreibt doch ob ihr meint, dass man damit die absoluten Grundlagen von DB unterrichten kann
Ich glaube nicht, dafuer ist der Code viel zu durcheinander und auch noch unnoetigerweise optimiert.
Warum keinen einfachen B*-Baum?
Warum keinen einfachen, stark befehlsreduzierten SQL-Parser?
Die Studenten muessen fuer die jetzige Ausgabe alleine schon sehr gut Javascript koennen, um den Code ueberhaupt lesen zu koennen. Vor allem, da die Kommentierung nur recht mager ausgefallen ist.so short
Christoph Zurnieden
-
Leider kann ich nach dem Anlegen meiner Tabelle nichts einfügen, da ich einen Error über ungültige Verbindungen erhalte.
Ausserdem ist mir aufgefallen, dass man keine zusammengesetzte Schlüssel angeben kann. Das wäre auf jeden Fall sinnvoll.Zumindest finde ich auf den ersten Blick das Interface zum Daten anlegen sehr intuitiv. Habe allerdings auch keine Abfragen gemacht, da das ja mit leeren Tabellen keinen Spass macht...
Beste Grüsse - Pygo
-
Leider kann ich nach dem Anlegen meiner Tabelle nichts einfügen, da ich einen Error über ungültige Verbindungen erhalte.
Kannst du genauer sagen, was du gemacht hast, damit ich den Fehler besser lokalisieren kann?
Ausserdem ist mir aufgefallen, dass man keine zusammengesetzte Schlüssel angeben kann. Das wäre auf jeden Fall sinnvoll.
Soweit bin ich noch nicht und ob das jemals kommt...wer weiß?
Danke fürs Feedback.
-
yo,
Ausserdem ist mir aufgefallen, dass man keine zusammengesetzte Schlüssel angeben kann. Das wäre auf jeden Fall sinnvoll.
Soweit bin ich noch nicht und ob das jemals kommt...wer weiß?
dies kommt doch des öfteren vor, zum beispiel bei N:M beziehungstabellen, wo die schlüssel der anderen tabellen zusammen den pk bilden. insofern macht es schon sinn, zusammengestzte schlüssel mit ins boot zu nehmen.
Ilja
-
dies kommt doch des öfteren vor, zum beispiel bei N:M beziehungstabellen, wo die schlüssel der anderen tabellen zusammen den pk bilden.
Kann man da nicht die Kombination Primärschlüssel,FremdSchlüssel,Fremdschlüssel machen?
Kennst du konkret ein Beispiel, wo sowas mal aufgetreten ist. Ich habe nämlich ein Problem mit genügend Beispielen. Ich weiß zwar wie das mit DB theoretisch geht, aber so richtig Praxiserfahrung konnte ich leider noch nicht sammeln.
-
yo,
Kann man da nicht die Kombination Primärschlüssel,FremdSchlüssel,Fremdschlüssel machen?
sicherlich ist das auch eine möglichkeit. aber zum einem soll deine seite ja lehren, sprich man sollte beide möglichkeiten kennen, um sich für die in einem speziellen fall optimale lösung entscheiden zu können.
zum anderen macht es sinn, den primary key über die beiden spalten zu bilden. erstens ist es eine spalte weniger und zweitens sollte man sowieso aus gründen der integrität einen unique und not null constraint über die beiden spalten legen. und die beiden sind nun mal die eigenschaften eines pk schlüssels.
Kennst du konkret ein Beispiel, wo sowas mal aufgetreten ist. Ich habe nämlich ein Problem mit genügend Beispielen. Ich weiß zwar wie das mit DB theoretisch geht, aber so richtig Praxiserfahrung konnte ich leider noch nicht sammeln.
beispiele entstehen immer bei n:m beziehungen zweier entitäten. dann braucht man nämlich eine weitere beziehungstabelle, um die beziehung bei rdbms abbilden zu können. ein beispiel dafür wäre die beziehung zwischen kunde und artikel, sie ist klassisch n:m. eine kunde kann mehrere artikel kaufen, ein artikel kann von mehreren kunden gekauft werden. das ist sicherlich eine vereinfachte darstellung und gibt raum für eine weiterführung. so kann eine kunde ein artikel nur einmal kaufen. was aber, wenn der gleiche kunde zu unterschiedlichen zeiten einen artikel nochmal kaufen will. dann nimmt man eben das datum mit in den pk rein, falls man davon ausgeht, nur eine bestellung des gleichen kunden pro tag. macht ja auch sinn ;-)
Ilja
-
-
-
-