dr.dimitri

Ander ausgedrückt, Du möchtest das implementieren was man "Blättern" nennt. Welche Datenbank verwendest Du? Oder Du suchst direkt nach Blättern und deiner DB in google, dort findest Du sofort diverse Beispiele. Dim

Ich glaub es geht eher darum, ein Create Table Script incl. aller Constraints und Indices zu generieren und nicht darum die Daten von A nach B zu verschieben. Sofern MSSQL kein Package a la DBMS_METADATA anbietet, muss man hierzu über die Metatabellen der Datenbank gehen und sich das ganze selbst zusammenbauen. Dim

Jep. Wird in anderen Foren auch so gemacht. Gfg. wird der OP auch mal darauf hingewiesen. Dim

Ich kenn mysql nicht aber ein par generelle Punkt fallen mir auf: mysql_query Du schickst keine Query (Abfrage=SELECT) sondern ein DML Statement. Ich vermute, PHP hat dafür eigene Methoden. echo 'Fehler'; Was soll man dazu sagen? :old Das ist ungefähr so, als ob man ein Auto in die Werkstatt bringt und sagt "es geht nicht" sich umdreht und wieder geht. Vielleicht würde dort sogar eine Fehlermeldung ausgegeben werden, die dir sagt wo Du suchen musst. Also mach eine vernünftige Fehlerbehandlung, dann bist Du vielleicht schon weiter. Funktioniert der LOAD Befehl eigentlich übers Netzwerk oder muss die DB lokalen Zugriff auf die Datei haben? Das wär auch noch ein Grund weswegen es nicht funktionert. Dim

Kannst ja mal posten ob es was gebracht hat. Dim

Wieso? das ist doch praktisch das gleiche. Über ip und host wird gejoint und das Datum ist die wohl am meisten einschränkende Bedingung. Sie verlangsamen DML Befehle, da sie natürlich immer mitgepflegt werden müssen. Ich würde diesen zusätzlichen index mal anlegen, da passiert nichts ausser, das es Plattenplatz kostet und Zeit in anspruch nimmt und dann nochmal testen, prüfen ob der Index verwendet wird (wovon ich ausgehe) und ob die Abfragedauer sich verbessert hat. Dim

Übertragen? Ja kann man. Automatisch? Nein Wunder gibt es leider auch in der IT nicht. Du brauchst ein passendes DB Modell, und dann ein Programm welches dir die Sachen exportiert und importiert. Wie die Daten verarbeitet werden müssen hängt aber von Deinen fachlichen Anforderungen ab. Dim

Die von mir von AE sicht her "betreute" DB ist etwa 1,2 Tb groB Von der Sicherung her kann jetzt nur sagen, was ich von unseren Admins so gehört hab. Jeden Tag incrementelle Backups und einmal die Woche ein full backup. Das das komplette zurückspielen ein weilchen dauern würde denk ich auch, aber dank Flashback table/query/database können kleinere Vergehen auch so behoben werden und ein kompletes Recovery hab ich bisher noch nie erleben müssen. Wie setzen auch SAN ein. das ganze läuft mit zwei RAC Knoten die jeweils ca. 15km voneinander entfernt sind. Die größe der anderen ca. 1000 Instancen (so um den Dreh rum) weiß ich nicht. Bewegen sich aber so im Bereich von einigen hundert MB bis in den TB Bereich hinein. Dim

Ja ein paar: WHERE l.host IS NOT NULL Die Bedingung kannst dir sparen, denn bei einem INNER JOIN werden NULL Werte nicht berücksichtigt (mal davon abgesehen, dass ein PK nie NULL sein kann). Auch ist NULL immer ungleich NULL. HOST und DATETIME sollten in einem zusammengesetzten Index indiziert sein. Damit kann in einem lesevorgang gejoint und eingeschränkt werden. AND d.dns LIKE 'hier steht der dns-name' Ist das tatsächlich eine LIKE Bedingung mit Jokerzeichen oder in Wirklichkeit eine verborgende = Bedingung? In diesem Fall sollte auch ein = verwendet werden. Wenn über msg wahlfrei gesucht werden soll, würde ich eine Volltextindizierung verwenden. Bei einem LIKE '%text%' kann der Index nicht verwendet werden. Nur wenn Du LIKE 'text%' schreibst. Die bereits vorgeschlagene Partitionierung ist auch eine Möglichkeit. Ich würde das Datum mal als möglichen Partitionsschlüssel ins Auge fassen. ip VARCHAR(32) Überleg dir, ob Du die IP als Zahl speichern (Punkte vor dem Einfügen entfernen) und die "echte" IP in einem extra Feld ablegen. Das hätte den Vorteil, dass der Index viel kleiner wird und die DB deshalb weniger verarbeiten muss. Die Berechnugn der Indexgröße bei mysql sieht etwa so aus: (länge+4)/0.67. Das wären bei 100 Mio IP-Adressen mit durchschnittlich sagen wir 12 Zeichen immerhin über 1,1GB. bei einem Integer wären es nur ca. 770MB. Also schon mal 30% weniger zu lesen bei einem Join. Problematisch wirds allerdings wenn ipv6 kommt, denn der größte nummerische Datentyp in mysql ist BIGINT und mit 64 Bit leider nur halb so breit wie benötigt. Überleg dir den Schritt also gut. Ist sowieso eher der letzte Schritt. Dim

So ich hab mir jetzt mal in Word Dein ER-Modell auf der 1. Seite angesehen (OpenOffice kann das nicht darstellen) und das ist ja komplett anders als die Modellierung Die Du in Access gemacht hast. Zwischen Mitarbeiter und Aufträge besteht keine 1:1 Beziehung. Die Werkstatt wäre schnell pleite. Es ist eine1:n Verbindung wie sie in Access auch richtig modelliert wurde. Ist mir auch gestern Abend noch eingefallen: Mit der 1:n Beziehung zwischen Aufträge und Reparaturen hast natürlich recht (die n:m Auflösungstabelle ist nicht direkt falsch aber macht unnötigen Aufwand), allerdings hast das in Access falsch abgebildet. In Reparaturen gehört die AuftragsNr. und aus Aufträge die Reparaturnummer raus. Dim

Hmm nicht ganz. Auftragsinhalt hat die AuftragsNr, die Reparaturnummer und einen eigene PK der aber sonst nirgends referenziert wird. Dim

Nein. Hier hast Du eine n:m Auflösungstabelle. Vorgänge verbinden Reparaturen mit der Art. Das gleiche musst Du auch bei Aufträge und Reparaturen machen. In der Tabelle Vorgänge ist nur das Feld Nr eindeutig. ArtNr und ReparaturNr können öfter vorkommen. Dim

Nein im Auftrag steht die Reparaturnummer. Die Reparaturnummer wiederum ist der PK der Tabelle Reparaturen und daher eindeutig. Ergo kannst Du in deinem Auftrag auf genau eine Reparatur verweisen. Dim

Nein. Aufträge - Reparaturen ist n:1 Da Du aber in der Praxis nicht ein und die selbe Reparatur einem anderen Auftrag zuweist, ist es faktisch eine 1:1 Beziehung. Eine Kunde hat einen oder mehrere Aufträge. Eine Auftrag beinhaltet eine oder mehrere Reparaturen. Dim

Ok schaut schon mal nicht schlecht aus. Die Kundennummer in "Reparaturen" ist redundant, da sie bereits in "Aufträge" abgelegt ist. In einer echten Anwendung würde man sowas aber durchaus machen um die Performance zu erhöhen. Das nennt man dann Nenormalisierung. Allerdings kann laut deinem Modell zu einem Auftrag auch immer nur eine Reparatur erfolgen. Was ist wenn am Auto mehr zu machen ist? Z.B. 2 Jahres Service und Kotflügel ausbeulen. Zwischen "Aufträge" und "Reparaturen" muss also eine n:m Beziehung hergestellt werden, welche über eine Beziehungstabelle aufgelöst wird (z.B. "Auftragsposition"). Bei "Reparaturen" und "Art" hast es richtig gemacht. So müsstest Du auch vorgehen, wenn z.B. zwei Mitarbeiter an einem Auftrag arbeiten müssen. Des weiteren ist das Attribut "AutoNr" in "Kunden" falsch. Wenn, dann besitzt ein Kunde ein oder mehrere Autos aber er hat keine Autonummer. Auch würde das der Forderung widersprechen, dass ein Kunde mehrere Autos in der Werkstatt haben kann. Für das geforderte ist die AutoNr in "Aufträge" ausreichend. Dim

Na dann sag endlich was Du machst und drucks hier nicht so rum. Und wenn du Personalverantwortung damit definierst Leute einzustellen, nein dann hab ich keine. Wenn du sie damit definierst sie was konstruktives zu bewerkstelligen zu lassen, nun dann hab ich vermutlich mehr als Du. Wie gesagt ich red hier nicht von einem Projekt das durch einen MA zum Scheitern verurteil ist, sondern von einer Baustelle mit ~50 Mitarbeiten. Dim

Naja mag sein, aber so wie Du das hier schreibst bist Du weder das eine noch das andere. Weder jemand der Leute einstellt, sonst würdest nicht imme rin der 3. person davon reden und auch keiner der ein projekt nach vorne bringt. Ausserdem hört sich das eher nach jemanden an, der für eine Leiharbeitsfirma Leute rekrutiert, denn wenn einer allein mal so eben ein Projekt ruiniert, dann hört sich das nicht sonderlich vertrauenserweckend an. Aber ich bin ja auch nur Chefentwickler in einem 15Mio Euro Projekt - was weiß ich schon. Dim

Erstelle ein ERM, in dem die Mitarbeiter, Aufträge und Kunden abgebildet werden können. Jeder Mitarbeiter kann nur eine Reparatur gleichzeitig ausführen. Eine Kunde kann mehrere Autos auf einmal in der Werkstatt haben. Zur Vereinfachung kann nur ein Auto gleichzeitig repariert werden. Zu jedem Kunden gibt es eine Kundenkarte, die die Rechungen und Einzelaufstellungen der durchgeführten Tätigkeiten sowie den durchführenden Mitarbeiter beinhaltet. Begründe Deine Ausführungen und lade ein entsprechendes Modell als Bild hoch. Erstellen kannst Du dies mit Visio, Access, Openoffice oder einem anderen Tool deiner Wahl. Solltest du das einigermaßen lösen können, bist schon recht nahe an einer (kleinen) "real wold application" dran. Es fehlt zwar noch das eine oder Detail andere aber für eine Schulaufgabe mit einer 1+ sollte das auf jeden Fall reichen. Für Fragen, Auskünfte und Korrekturen stehen wir gerne zur Verfügung. Dim

Ja da hast Du recht. Und so wie Du dich aufbrezelst solltest Du eher unten stehen als wichtige Entscheidungen zu treffen. Dim

Hmm nur einer *snif*

Ach das sieht man? Direkt mal nachschauen...

Das kann man so pauschal nicht sagen. Sofern man nicht einen extrem schlechten DB-treiber verwendet, ist im Prinzip kein Unterschied wie ein SQL zur Ausführung gebracht wird - es läuft beidemale innerhalb des Servers. Unterschiede können sich im Ausführungsplan ergeben, was aber dann andere Gründe hat. Grundsätzlich bin ich jedoch ein klarer Befüworter von SP. Nicht unbedingt aus Performance sondern aus Kapselungs- und Sicherheitsgründen. Dim

Ok. Dann halt ich eine reine Webanwendung dafür aber auch eher für ungeeignet, denn ein statuslose Protokoll ist für solche OLAP Auswertungen m.M. nach ungeeignet (Beispiel Browser schließen, einen neuen öffnen und neue Abfrage starten etc). Ich würd das so implementieren, dass Du über die Weboberfläche einen Job antriggerst der dann in der DB läuft und dem User das Ergebnis zur Verfügung stellt (z.B. in dem eine Zwischentabelle befüllt wird o.Ä.). Während der Laufzeit bekommt der User nur eine Statusmeldung angezeigt, welche von dem Job in eine Statustabelle geschrieben wird und von dir periodisch ausgelesen wird. Die Webseite kannst ja z.B. alle 5 Sekunden refreshen lassen. Solange ein Job läuft kann der User keinen neuen starten. Ist der Job fertig, wird das ebenfalls vermerkt und das Ergebnis kann angezeigt werden (in welcher Form auch immer). Dim

Nein kann ich nicht. Du hast als Ergebnismenge ja wohl nicht zehntausende Sätze oder? Indizier die Tabelle vernünftig, dann ist das eine Sache von Sekunden(bruchteilen). Dim

Hi, die Zeit als eigene Entität würde nur dann Sinn machen, wenn Du einen begrenzte Anzahl von Zeiten hättest. Da die Anzahl der Messergebnisse aber praktisch unbegrenzt sind solange Deine Anwendung läuft, ist es viel Sinnvoller und gleichzeitig einfacher zu Implementieren wenn die zeit als Attribut einer Messung gesehen wird. Mag sein, dass dann doppelte Werte in den eigenen zeilen stehen, aber es würde auch niemand auf die Idee kommen z.B. in einer Adressverwaltung eine eigene Tabelle mit allen Datümern eines Jahres einzuführen nur damit ein Geburtsdatum nicht redundant abgelegt wird. Des weiteren geh ich davon aus, dass Du auch noch nie eine Anwendung geschrieben hast die auf ein solches ERM zugreift. Du wirst dann sehr schnell sehen, dass jede Entität die man hinzufügt die ganze Zugriffsschicht komplexer macht. Daher sollte man auf just for fun Tabellen verzichten. Ja auch das ist ein häufiger Fehler. Designe deine Application und die DB immer so, dass sie von Anfang an so performant wie möglich ist. Steht die Anwendung und die DB, dann ist nachträgliches Tuning immer sehr viel schwieriger. Im übrigen hängst Du ja auch keinen Anker an dein Auto nur weil Du vielleicht momentan nicht schneller als 100 fahren möchtest. Dim