Dienstag, 26. April 2005
Neuer SQL Server im Betrieb...
christian.schober.uni-linz, 09:51h
...nach einigen Missverständnissen konnte in Zusammenarbeit mit der Servergruppe die Fehlfunktionen behoben werden.
Problem war case senitivity von Tabellennahmen. Es wurden die Tabellen gelöscht und mit entsprechender Schreibung (in Anlehung and das Datenmodell) neu hinaufgeladen.
Es wurde die gesamte Funktionalität überprüft. Dabei stellte sich heraus, dass es Probleme mit dem SUM Befehl gibt. Wenn sich dieser auf eine Multiplikation bezieht liefert er kein Ergebnis. Bsp: SUM (Buch * Preis)
Es gibt keine Fehlermeldung bezüglich einer falschen Syntax. Auch direkt am Server, also ohne die PHP Abfrage tritt das Problem auf. Alle anderen Abfragen funktionieren. Der Zugang ist http://sql.idv-edu.uni-linz.ac.at. Es funktioniert aber auch die alte Domain http://sql.idv.edu.
Problem war case senitivity von Tabellennahmen. Es wurden die Tabellen gelöscht und mit entsprechender Schreibung (in Anlehung and das Datenmodell) neu hinaufgeladen.
Es wurde die gesamte Funktionalität überprüft. Dabei stellte sich heraus, dass es Probleme mit dem SUM Befehl gibt. Wenn sich dieser auf eine Multiplikation bezieht liefert er kein Ergebnis. Bsp: SUM (Buch * Preis)
Es gibt keine Fehlermeldung bezüglich einer falschen Syntax. Auch direkt am Server, also ohne die PHP Abfrage tritt das Problem auf. Alle anderen Abfragen funktionieren. Der Zugang ist http://sql.idv-edu.uni-linz.ac.at. Es funktioniert aber auch die alte Domain http://sql.idv.edu.
... comment
Hans.Mittendorfer.Uni-Linz,
Dienstag, 26. April 2005, 12:17
die Funktionstüchtigkeit ..
.. kann ich aufgrund zufällig gewählter Tests betätigen.
Die Summenbildung, wie im Beispiel:
SELECT Artikel.Auftragsnummer, SUM (Buch.Preis * Artikel.Menge) FROM Buch, Artikel WHERE (Artikel.Buchnummer = Buch.Nr) GROUP BY Artikel.Auftragsnummer ORDER BY 2 DESC
führt zu einem Syntaxfehler, vermutlich weil ein Leezeichen zwischen Funktionsname und Argumentenliste besteht. OHNE LEERZEICHEN:
SELECT Artikel.Auftragsnummer, SUM(Buch.Preis * Artikel.Menge) FROM Buch, Artikel WHERE (Artikel.Buchnummer = Buch.Nr) GROUP BY Artikel.Auftragsnummer ORDER BY 2 DESC
Dauert das Ergebnis offensichtlich sehr lang - zu lage.
Dass die Funktion SUM grundsätzlich funktioniert "beweist" nachfolgende Abfrage:
SELECT Artikel.Auftragsnummer, SUM(Buch.Preis * Artikel.Menge)
FROM Buch, Artikel
WHERE (Artikel.Buchnummer = Buch.Nr) AND
Artikel.Auftragsnummer="7"
GROUP BY Artikel.Auftragsnummer
Desgleichen sind weitere Funktionen (MIN, MAX, ...) funktionstüchtig.
Mag sein, dass gewisse Abfragen, die im alten, kleineren Datenbestand noch machbar waren, jetzt, im größeren Datenbestand nicht mehr praktikabel sind.
To Do's:
Die Summenbildung, wie im Beispiel:
SELECT Artikel.Auftragsnummer, SUM (Buch.Preis * Artikel.Menge) FROM Buch, Artikel WHERE (Artikel.Buchnummer = Buch.Nr) GROUP BY Artikel.Auftragsnummer ORDER BY 2 DESC
führt zu einem Syntaxfehler, vermutlich weil ein Leezeichen zwischen Funktionsname und Argumentenliste besteht. OHNE LEERZEICHEN:
SELECT Artikel.Auftragsnummer, SUM(Buch.Preis * Artikel.Menge) FROM Buch, Artikel WHERE (Artikel.Buchnummer = Buch.Nr) GROUP BY Artikel.Auftragsnummer ORDER BY 2 DESC
Dauert das Ergebnis offensichtlich sehr lang - zu lage.
Dass die Funktion SUM grundsätzlich funktioniert "beweist" nachfolgende Abfrage:
SELECT Artikel.Auftragsnummer, SUM(Buch.Preis * Artikel.Menge)
FROM Buch, Artikel
WHERE (Artikel.Buchnummer = Buch.Nr) AND
Artikel.Auftragsnummer="7"
GROUP BY Artikel.Auftragsnummer
Desgleichen sind weitere Funktionen (MIN, MAX, ...) funktionstüchtig.
Mag sein, dass gewisse Abfragen, die im alten, kleineren Datenbestand noch machbar waren, jetzt, im größeren Datenbestand nicht mehr praktikabel sind.
To Do's:
- Diskutieren Sie diesen Sachverhalt mit jener Gruppe, die den Datenbstand erweitert hat.
- Stellen Sie fest, wo "unmachbare" Abfragen in den Dokumentationen vorkommen
- Ändern Sie diese ggfs.
- Entfernen Sie bitte den Hinweis auf die Onlinebefragung, sowohl im Menü, als auch durch die JAVASCRPIT-Anweisung
... link
josef.poley.uni-linz,
Dienstag, 26. April 2005, 16:51
To Do's
Ich habe heute gemeinsam mit Christian Schober aus der Gruppe "SQL-Veränderung der Inhalte" (diese hatte die Erweiterung des Datenbestandes zur Aufgabe) die Aktualisierung der Datenbank (d.h. genauer gesagt die Umbenennung der Tabellennamen) durchgeführt. Dabei konnte die Datenbankstruktur in phpMyAdmin überprüft (keine Abweichung im Vergleich mit der "alten" Datenbank) sowie Abfragen auf Funktionalität getestet werden - mit Erfolg.
Lediglich bei den SQL-Beispielen, die den SUM-Befehl enthielten, kam vom Server keine Rückmeldung (dies ist nicht gleichzusetzen mit einem Syntaxfehler, da ein solcher bei abgeänderter Anweisung ausgegeben wird). Allerdings funktionieren einfache Abfragen mit SUM in der interaktiven Abfrage ohne Probleme.
Derzeit wird hinsichtlich dieses Problems nach einer Erklärung bzw. Lösung gesucht.
Die Onlinebefragung wird in Bälde entfernt.
Lediglich bei den SQL-Beispielen, die den SUM-Befehl enthielten, kam vom Server keine Rückmeldung (dies ist nicht gleichzusetzen mit einem Syntaxfehler, da ein solcher bei abgeänderter Anweisung ausgegeben wird). Allerdings funktionieren einfache Abfragen mit SUM in der interaktiven Abfrage ohne Probleme.
Derzeit wird hinsichtlich dieses Problems nach einer Erklärung bzw. Lösung gesucht.
Die Onlinebefragung wird in Bälde entfernt.
... link
Hans.Mittendorfer.Uni-Linz,
Donnerstag, 28. April 2005, 14:21
betrifft das Nichtfunktionieren ..
.. der Funktion "sum" nur das Web-Interface, oder tritt das beschriebene Phänomen auch bei Datenbankabfragen ohne Web auf ?
Ich kann darüberhinaus den Verdacht nicht loswerden, dass es auch ein Performanceproblem ist.
Führen Sie z.B. nachfolgende Abfrage aus:
select Artikel.Auftragsnummer, sum(Artikel.Menge * Buch.Preis) from Artikel, Buch
where Buch.Nr = Artikel.Buchnummer
and Artikel.auftragsnummer between 40 and 50
group by Artikel.Auftragsnummer
order by 2
und erhöhen sodann systematisch den Bereich:
between 40 and 60 - oder
between 30 an 70 usw.
Sie werden sehen, wie die Antwortzeit merklich (exponentiell ?) steigt.
Bei dieser Gelegenheit zeigt sich aber auch, dass die generierten Daten offensichtlich NICHT gewissenhaft erzeugt wurden. Wie könnte es sonst sein, dass z.B die Auftragsnummern: 30, 35, 40, 45, 50, 55, 60, 65, 70, 75 und 80 dieselbe Auftragssumme erzeugen, nämlich: 128,59.
Handelt es sich etwa um einfache Kopien ?
Vor allem der Umstand, dass die Gruppe(n) selber keine, bzw. zu wenig Tests der von Ihnen produzierten Egebnisse machten und auch nach der Besprechung immer noch nicht machen, stimmt mich nicht gerade positiv.
H. Mittendorfer
Ich kann darüberhinaus den Verdacht nicht loswerden, dass es auch ein Performanceproblem ist.
Führen Sie z.B. nachfolgende Abfrage aus:
select Artikel.Auftragsnummer, sum(Artikel.Menge * Buch.Preis) from Artikel, Buch
where Buch.Nr = Artikel.Buchnummer
and Artikel.auftragsnummer between 40 and 50
group by Artikel.Auftragsnummer
order by 2
und erhöhen sodann systematisch den Bereich:
between 40 and 60 - oder
between 30 an 70 usw.
Sie werden sehen, wie die Antwortzeit merklich (exponentiell ?) steigt.
Bei dieser Gelegenheit zeigt sich aber auch, dass die generierten Daten offensichtlich NICHT gewissenhaft erzeugt wurden. Wie könnte es sonst sein, dass z.B die Auftragsnummern: 30, 35, 40, 45, 50, 55, 60, 65, 70, 75 und 80 dieselbe Auftragssumme erzeugen, nämlich: 128,59.
Handelt es sich etwa um einfache Kopien ?
Vor allem der Umstand, dass die Gruppe(n) selber keine, bzw. zu wenig Tests der von Ihnen produzierten Egebnisse machten und auch nach der Besprechung immer noch nicht machen, stimmt mich nicht gerade positiv.
H. Mittendorfer
... link
christian.schober.uni-linz,
Freitag, 29. April 2005, 12:23
Kommentar...
| SELECT Artikel.Auftragsnummer, Artikel.Buchnummer, Buch.Titel, Artikel.Menge, Buch.Preis
FROM Buch, Artikel AND (Artikel.Auftragsnummer=30 OR Artikel.Auftragsnummer=35 OR Artikel.Auftragsnummer=40 OR Artikel.Auftragsnummer=45) ORDER BY Artikel.Auftragsnummer |
Bei den oben angeführten kritisierten Aufträgen handelt es sich um Kleinaufträge. Die gleichen Umsatzwerte sind auf standardisierte Preise der Schulbücher zurückzuführen. Angemerkt sei, dass eine Veränderung des Buch-, und Verlagbestandes nicht Aufgabe dieser Gruppe war.
Es stellt sich heraus, dass die 961 Aufträge mit insgesamt 6882 Artikeln im Umsatzwert eine sehr gute Varianz aufweisen!
Ein Performanceproblem kann ich bei aktuellem Stand der Tests bestätigen, obwohl hier noch Prüfungen ausstehen.
...
... link
... comment
Online for 7508 days
Last update: 2005.06.15, 09:20
Last update: 2005.06.15, 09:20
status
You're not logged in ... login
menu
search
calendar
April 2005 |
||||||
Mo |
Di |
Mi |
Do |
Fr |
Sa |
So |
1 |
2 |
3 |
||||
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
27 |
28 |
29 |
30 |
||
recent updates
Anleitung zur Datenmodifikation
Diese Information soll jenen dienen, die uns nachfolgend...
Diese Information soll jenen dienen, die uns nachfolgend...
by christian.schober.uni-linz (2005.06.15, 09:20)
Dann haben Sie jetzt...
Ich ersuche Sie, sofern dies noch nicht an anderer...
Ich ersuche Sie, sofern dies noch nicht an anderer...
by Hans.Mittendorfer.Uni-Linz (2005.06.02, 15:26)
Datenverbesserung
Die Daten haben sich nicht auf unerklärliche Weise...
Die Daten haben sich nicht auf unerklärliche Weise...
by christian.schober.uni-linz (2005.06.02, 12:31)
es hat den Anschein,...
.. dass sich mit der Reparatur der Performance mindernden...
.. dass sich mit der Reparatur der Performance mindernden...
by Hans.Mittendorfer.Uni-Linz (2005.06.02, 11:22)
Ergebnisbericht
Die technischen Probleme sind gelöst. Diese waren...
Die technischen Probleme sind gelöst. Diese waren...
by christian.schober.uni-linz (2005.06.02, 10:46)
