dr.dimitri

Dann wäre eine Apex Anwendung, in der Du die Reports hinterlegst wohl wirklich das Einfachste. Du kannst die in XE enthaltene Version 2.1 auch auf die aktuelle 3.1.2er Version upgraden und hast dann u.a. auch die sog. interaktiven Reports zur Verfügung. Dim

Ist das jetzt als Abschreckung oder als Aufmunterung gedacht? Dim

Ist schon Blödsinn - wenn auch aus einem anderen Grund, denn ein Einschreiben mit Rückschein an eine Firma zu schicken, die, wie schon erwähnt, Betriebsferien hat, ist die sicherste Möglichkeit dafür zu sorgen, dass der Brief zurück an den Absender geht. Mission erfüllt. :upps Dim

Hi, die Anforderung ist etwas schwammig. SQLs kannst Du von jedem Rechner aus ausführen lassen, der ein entsprechendes Anwendungsprogramm und eine Netzwerkverbindung zur Datenbank hat. Das kann eine mit Apex geschriebene Weboberfläche sein, ein Kommandozeilentool wie sqlplus, der SQL Developer oder auch ein selbstgeschriebenes Javaprogramm. Also was genau verbirgt sich hinter "die erstellten Reports auf einem Client laufen lassen"? Dim

Was ist das denn für ne Aussage? Dim

Hi, SQL ist eine mengenorientierte Abfragesprache und keine Programmiersprache. Wenn Du wissen möchtest, ob in der Tabelle Einträge sind, dann verwende die COUNT Funktion ggf. mit der TOP Klausel. In T-SQL oder PL/SQL muss das Ergebnis eines SQLs immer auch irgendwo abgespeichert werden. Einfach ein SQL ausführen funktioniert nicht. Du musst einen explizieten oder Implizieten Cursor verwenden, damit die DB auch weiß wohin denn das Ergebnis abgelegt werden soll. Mein Rat: Such dir ein Tutorial im Internet oder besser noch besorg dir ein gutes Buch über den SQL Server (die Bewertungen bei amazon helfen bei der Auswahl). Ansonsten dürften sich deine Ersten Schritte unnötig schwerer als nötig gestalten. Den Kaufpreis des Buches kannst übrigends von der Steuer absetzen (evtl. ist noch eine Bestätigung des AG nötig). Dim

Dann würd ich dir schon mal dieses oder dieses Buch empfehlen, damit Du auch mit- oder besser noch fundiert dagegen reden kannst. Bei der Gelegenheit könnte man sich ja auch mal andere Provider ansehen, denn besonders kundenfreundlich hört sich deiner jetzt nicht an. Dim

Das konnte auch schon die 7er. Das hängt jetzt aber nicht von der Db ab. Viel CPU verbrauch bedeutet auch nicht automatisch, dass die Verarbeitung schnell ist. Handelt es sich um einen Batchprozess? Ist die Query entsprechend optimiert sind aktuelle Tabellenstatistiken erfasst? Wenn Oracle z.B. aufgrund felender/alter Tabellenstatistiken einen falschen Plan ermittelt, kann es z.B. sein, dass die ganze zeit nur von der Platte gelesen wird und Oracle nur drauf wartet, dass die Daten häppchenweise kommen. Da kann natürlich auch die CPU nicht ausgelastet werden. Dann solltest diesem Dienstleister den Auftrag geben deine Session zu überwachen, damit evtl. auftretende Engpässe erkannt werden können. An Oracle liegt es, rein technisch gesehen, nicht, dass nicht alle CPUs verwendet werden können - es müssen aber natürlich auch die entsprechenden Rahmenbedingungen vorhanden sein. Wär nicht schlecht, wenn Du noch etwas mehr Informationen über die AW bzw. den Batchlauf etc schreibst. Dim

Welche Auswirkung hat ein COMMIT auf diese drei Komponenten? Ich würde mal behaupten keine. Dim

Das sagt erstmal garnichts. Du wirst immer Waits bekommen, die Frage ist nur, wie hoch sie sind und in welchem Verhältnis sie zur Gesamtlaufzeit stehen. Daher wäre wichtig zu sehen, wieviel % der Laufzweit wirklich darauf gewartet wurde. Bei einem Commit wird nämlich der Inhalt des Logbuffers in die REDO Logs geschrieben. Der Logbuffer wiederum ist mit ein paar MB relativ klein und wir auch unabhängig von einem Commit alle 3 Sekunden oder wenn 1MB Speicher darin belegt ist in der REDO Logs geschrieben. Da Du anscheinen einen conventional load machst, wird die Frequenz der commits über den Parameter ROWS=xy festgelegt. Default sind 64 glaub ich. Wenn Du die Option DIRECT=TRUE angiebst, führst Du einen sog. direct path load aus. Dabei werden zum einen keine REDO Logs geschrieben (ausser für die betroffenen Indices), und zum anderen wird der Inahlt an die Tabelle angehängt d.h. Platz, der innerhalb der Tabelle per Delete Statement frei geworden ist wird für den load nicht wieder verwendet. 9 Millionen Sätze sollten in ein paar Minuten in der DB sein, sofern Du nicht zig Indieces auf der Tabelle hast und die CPU, Platten und die Instance einigermaßen ausreichen dimensioniert sind. Dim

Der ORA-06000 ist ein allgemeiner schwerer Fehler, der viele Gründe haben kann. Daher wird der Support auch diverse dump files haben wollen um die genaue Ursache bestimmen zu können. Anrufen? Da macht man einen tar in metalink auf. Anrufen würd ich da auch nie. Dim

Der Support. Ein ORA-0600 bedeutet nichts anderes als: Informier den Support falls das Problem weiterhin besteht. Alternativ kannst ja mal bei metalink suchen ob da was dazu steht. Dim

ich würd allerdings zur 1er Version des VMWare Servers raten. Die Version 2 hat ein unmögliches Webinterface. Dim

Crosspost Dim

Jetzt hast aber eine neue Beziehung eingefügt. Die ist rein fachlich natürlich richtig, macht das ganze aber wieder komplexer. Ein Interpret kann mehrere Produzenten haben, und ein Produzent hat sicherlich auch mehrere Interpreten. Sprich das ganze ist eine n:m Beziehung, die durch eine Zwischentabelle aufgelöst werden muss. Entweder Du läßt die Verbindung weg, oder Du löst die n:m Beziehung auf. Für jedes Lied hast Du mindestens 1 Eintrag in der INTERPRET_ART (falls es ein Duett ist auch zwei - muss ja deshalb noch keine Band sein). Das ist absolut ok und widerspricht auch nicht der 3 NF. Stell dir eine Aufgabenstellung vor, die verlangt alle Lieder zu ermitteln die eine Band gemacht hat. Du würdet mit der Band_ID und den TYP=Band auf die INTERPRET_ID selektieren und bekommst dann eine Menge X von LIED_ID. Diese kannst dann mit der Tabelle LIED verknüpfen und erhältst die Lieder dieser Band. Das ganze geht in einem einzigen SQL und nennt sich dann JOIN. Punkt für dich, das Feld hab ich glatt vergessen . Das müsstest Du noch aufnehmen. Abhängig vom Wert des Feldes TYP weiß man dann, ob man in der Tabelle Künstler oder in der Tabelle Band suchen muss. Ich würd mal behaupten ja. Keine Redundanten Einträge, keine Werte, die nicht vom PK abhängen, alle Spalten enthalten atomare Werte. Außer ich hab hier was übersehen. In der Praxis würde man natürlich spätestens jetzt beginnen dein Modell zu Denormalisieren. Sprich gezielt gegen die 3 NF zu verstoßen und Redundanzen einzuführen. Eine ER Modell in der 3 NF kann zum einen sehr komplex werden (siehst ja wieviele Tabellen eine einfache Plattenverwaltung braucht) und zum anderen ist es auch recht langsam wenn man sich durch viele Tabellen durchjoinen muss. Dim

Fast. Ein Interpret produziert keine Produzenten oder? Ein Produzent produziert eine CD. Dim

Des weiteren ist, wie schon angesprochen, das Statement ohne ORDER BY absolut witzlos, da es ansonsten keine definierte Reihenfolge gibt. Dim

Naja LIMIT gibts in MSSQL nicht, das heißt dort TOP, aber es sollte auch etwas eleganter gehen: T-SQL: Paging with ROW_NUMBER() Im Prinzip ist das nichts anderes als Paging. Dim

Fast. In INTERPRET gehört noch die LiedID (dafür die ART_ID aus LIED heraus). Des weiteren produziert ein Interpret keine CD. Die Entität Produzent fehlt bei dir komplett. Eine Produzent wäre z.B. Dieter Bohlen, der "Künstler" Marc Mattlock und das Label EMI (keine Ahnung ob das Stimmt nur mal als Beispiel). Möchtest Du z.B. wissen, welche Band welche Lieder hat, dann kannst Du mit der bandID und dem passenden typ in der Tabelle INTERPRET selektieren und bekommst deine LiedIDs. Damit kanns wiederum in LIEB weiterselektieren und bekommst die CDs auf denen die Lieder sind. Über die CD wiederum das Label etc. Das sind die Wege die du mit diesem ER Modell dann gehen musst um die gewünschte Information zu bekommen.

Ja schon. Band und Künsler sollen weder eine direkte Verbindung zu Lied noch zu CD haben. Genau dafür ist ja die Tabelle INTERPRET da. Wenn ich wissen will, wer ein Lied geschrieben hat, dann muss ich über INTERPRET gehen. Wenn ich wissen will, welche Künstler oder Bands auf meiner Compilation sind, muss ich ebenso über INTERPRET gehen. Momentan verteilst deine Künstler und Band IDs auf alle möglichen Tabellen. Der zentrale Punkt ist das Lied. Am Lied hängt die CD und der Interpret. Über den Interpret bekomme ich den Künstler bzw. die Band heraus. Dim

Nein das musst Du anders lesen. - Ein Album hat einen Interpreten (ein Interpret kann ein oder mehrere Alben haben) - Ein Interpret kann ein Künstler (natürliche Person) oder eine Band sein - Eine Band besteht aus Bandmitgliedern Mit diesem Modell kannst Du z.B. auch herausfinden, welcher Künstler in welchen Bands war (oder ob er überhaupt jemals in einer war): Interessanter ist allerdings die Frage, ob Dein Lehrer soviel Praxiserfahrung hat, um die Flexibilität einer solchen Struktur zu erkennen. Ach ja, da es um eine Benotung geht (hab ich glatt verdrängt) solltest Du das Musikformat vielleicht doch in eine eigene Entität verlagern, auch wenn man das in der Praxis wohl nicht so machen würde... Dim

Mal angenommen, Du hast 10000 Lieder. 2000 davon sind im flac und 8000 davon im mp3 Format. Wenn Du jetzt von den flacs 500 nach mp3 umkodierst, dann änderst Du doch nicht die Lookuptabelle, da ansonsten auch die restlichen 1500 flac Dateien als mp3 gelten würden. Ausserdem ist es absolut kein Problem 100 oder 10000 Datensätze mit einem SQL zu ändern. Du brauchst in Deinem Programm eben eine entsprechende Möglichkeit das Format batchmäßig zu ändern. Ja hast Du. Über die Tabelle INTERPRET verzweigt dein Programm anhand des Typs links oder rechts rum und geht entweder direkt zur natürlichen Person oder erstmal zur Band, die eine Klammer um eine Gruppe von Personen bildet. Dim

Hmm welche meiner Anmerkungen hast Du jetzt konkret umgesetzt? Die wichtigsten Punkte sind immer noch so. Dim

Hmm naja aber auch nur auf einen sehr flüchtigen ersten Blick. Das DB Modell ist meiner Meinung nach total übernormalisiert bzw. auch falsch designed. - Die Beziehung Lied - Format passt nicht. Ein Lied hat genau ein Format. Ist das gleiche Lied in mehreren Formaten in deiner Sammlung, dann muss es auch mehrmals aufgeführt werden. Stell dir z.B. eine Erweitung vor, mit der Du einen Playlist abbilden möchtest. Dann hättest Du keine Möglichkeit festzustellen ob die mp3 oder die flac version in einer bestimmten PL ist. Damit kann das Format als Tabelle entfallen und wird als Attribut der Tabelle Lied eingeführt. - Das Problem, das ein Künstler sowohl eine einzelne Person als auch eine Band sein kann, würd ich so lösen: Du führst eine Zuordnungstabelle INTERPRET ein. Dort gibt es eine Spalte TYP, anhand derer Du festmachst, ob der Interpret eine Band oder eine natürliche Person ist. Ist ersteres der Fall, kannst Du direkt eine Verbindung zur Künstertabelle machen, andernfalls joinst Du zuerst mit einer neuen Tabelle BAND, in der die gewünschten Daten zur Band liegen (Gründungsjahr etc etc). Zwischen BAND und KÜNSTLER gibt es dann wiederum eine n:m Auflösungstabelle BANDMITGLIED, die einen Künstler mit einer Band verbindet. Falls gewünscht, kannst dann in BANDMITGLIEDER auch noch die Information ablegen (bzw. den Schlüssel dazu) welche Funktion diese Person in dieser Band hatte (Sänger, Schlagzeuger, Kaffeekocher etc etc.) - Die Verbindung Album - Lied ist viel zu umständlich. Ich würde die Verknüpfung so machen: Album Lieder 1:n Album Interpret n:1 Album CD 1:n (evtl. hast ja ein Album doppelt, falls das nicht vorgesehen sein soll kanns CD auch weglassen) - Die Tabelle GESCHLECHT weglassen. Das ist ein Attribut von KÜNSTLER - Wofür ist die Tabelle LÄNDER gut? Ausserdem sollte man immer den Singular für den Tabellennamen verwenden - Wofür ist die Tabelle ALBUMTYP? - Die Musikrichtung würde ich an's Album hängen. Das ist mir mal so auf den zweiten Blick aufgefallen. Die Kunst ein gutes ER Modell zu erstellen liegt nicht darin, alles Mögliche und Unmögliche in Entitäten aufzusplitten und die Normalisierung auf die Spitze zu treiben, sondern darin, die richtige Balance zwischen Wartbarkeit, Performance und Flexibilität herzustellen. Jede Tabelle in einem ER Modell muss später mittels Programmcode befüllt werden. Bei Änderungen an den Daten müssen entsprechende Sperren und Lockingmechanismen implementiert werden (zumindest in einer Multiuserumgebung). Damit steigt der Aufwand natürlich überproportional zur Anzahl der Tabellen - aber das wirst Du merken, wenn Du beginnst das Programm zu deinem ER-Modell zu schreiben Dim

Also einen Flyer würd ich da eher nicht reinlegen. Aber Du kannst und solltest das im Lebenslauf bzw. im Anschreiben natürlich (deutlich) angeben. Allerdings würd ich mich eher fragen was dann aus deinem Gewerbe wird. So weitermachen wie bisher wird mit ziemlicher Sicherheit nicht gehen. Dim