Datenbanken

Datenbanken

This thread has been closed so unfortunately you can't post here any more.

Posts 11-19 of 19
  • Post visible to registered members
  • Dirk Gunsthövel
    Dirk Gunsthövel    Premium Member
    The company name is only visible to registered members.
    Re^9: MySQL mehrere relationelle Tabellen in einem Query?
    Hallo,

    Dr. Ralph Leonhardt schrieb:
    Ich zitiere mal aus dem SQL-92 Standard:
    " b) If the <from clause> contains more than one <table reference>
    with no intervening <derived table> or <joined table>, then
    the result of the <from clause> is the extended Cartesian
    product of the tables identified by those <table reference>s.
     
    M.a.W. eine standardkonforme Datenbank muß ein Kartesisches Produkt bei einm Cross join erzeugen.
    hierbei handelt es sich um ein immer wieder vorkommendes
    Missverständnis. Hier steht im weiteren die mengentheoretische
    Definition des Ergebnisses. Diese Notation ist sinnvoll, da sie
    mathematisch überprüfbar ist. Hier steht NICHT, dass man das
    karthesische Produkt in jedem Fall berechnen muss (falls Ihnen der
    Gedanke hilft: das karthesische Produkt existiert auch, wenn man es
    nicht berechnet). Das Ergebnis muss lediglich dem Ergebnis exakt
    entsprechen, dass man erhalten WÜRDE, wenn man dies so machen
    würde.

    Anders: Eine Datenbank ist (betrachtet man mal nur selects)
    eine Resultseterzeugungsmaschine. Sie ist Ansi-92 konform, wenn
    bei jeder query das rauskommt, was nach Ansi-92 rauskommen
    muss. Ansi-92 definiert die Schritte von der Query zum Ergebnis
    mengentheoretisch um eine Überprüfung der Korrektheit der
    Ergebnisse zu erlauben. Das heisst aber mitnichten, dass man
    genau diese Schritte in genau dieser Reihenfolge machen muss.

    Noch anders: ich möchte, dass Sie ein Programm schreiben, das
    in endlicher Zeit testet, ob eine vorgegebene Zahl prim ist und
    definiere dazu:
    (1)"Eine natürliche Zahl a>1 ist prim, wenn für alle b>1 b!= a gilt:
    b ist nicht Teiler von a".
    Folgend Ihrer Sichtweise kann es ein solches Programm nicht
    geben. In der Definition steht ja, dass man jedes b>1, b!=a
    einzeln auf die Teilereigenschaft testen muss, was ganz sicher
    unendlich lange dauert. Das Argument, dass b>a NIE
    Teiler von a sein kann, zieht deshalb nicht.
    Wir würden uns bestimmt daruf einigen können, die Definition
    in eine äquivalente zu modifizieren:
    (2)"Eine natürliche Zahl a>1 ist prim, wenn für alle b>1 b< a gilt:
    b ist nicht Teiler von a".
    Schon wäre das Problem gelöst und die Definition würde direkt
    die Vorgehensweise der Implementation induzieren (wenn es
    auch effizientere gibt ;-) )
    Mathematiker würden dennoch Definition 1 stets vorziehen,
    weil sie weniger unnötige Voraussetzungen hat.

    sql-92 ist Mathematik und nicht Algorithmik.

    Umsetzung in einer Implementation ist etwas ganz anderes -
    auch hierzu gibt es haufenweise Theorie. Einige Stichworte
    hatte ich schon genannt. Bei den meisten Datenbanksystemen
    bekommt man einen guten Eindruck davon, wenn man die
    spezifischen Explain- Outputs ansieht. Bei MySql zum Beispiel:
    http://dev.mysql.com/doc/refman/5.1/de/explain.html
    Andere wie zum Beispiel DB2, Oracle oder Informix sind
    da noch plappermäuliger. Schönes Beispiel für Informix:
    http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.j...

    Übrigens: in Ihrem 30 Mio Beispiel, in dem Sie davon ausgehen,
    dass mehrere Milliarden rows im tempspce als karthesisches
    Produkt erzeugt werden, schreiben Sie, dass Sie hoffen, dass
    die beteiligten Tabellen vernünftige Indexes haben. Welche Rolle
    sollten diese denn spielen, wenn die Filterkriterien aus dem
    Where-Part sowieso auf das Monster im tempspace statt auf die
    beteiligten Tabellen angewendet werden?

    Gruss,
    Dirk Gunsthövel
    • 23 Oct 2008, 9:22 pm
  • Christoph Ingenhaag
    Christoph Ingenhaag    Premium Member
    The company name is only visible to registered members.
    Re^10: MySQL mehrere relationelle Tabellen in einem Query?
    Hallo Herr Gunsthövel ,

    sehr schöner Beitrag!

    Eine Anmerkung von mir, die vielleicht ein bisschen off topic ist:

    Umsetzung in einer Implementation ist etwas ganz anderes -
    auch hierzu gibt es haufenweise Theorie. Einige Stichworte
    hatte ich schon genannt. Bei den meisten Datenbanksystemen
    bekommt man einen guten Eindruck davon, wenn man die
    spezifischen Explain- Outputs ansieht. Bei MySql zum Beispiel:
    http://dev.mysql.com/doc/refman/5.1/de/explain.html
    Andere wie zum Beispiel DB2, Oracle oder Informix sind
    da noch plappermäuliger. Schönes Beispiel für Informix:
    http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.j...
    com.ibm.perf.doc/perf282.htm
    in Zusammenhang mit diesem Zitat:
    Selbst der MS-SQL Optimizer, der nicht gerade für seine Brillianz bekannt ist,
    käme nicht auf solche Ideen ;-)
    Mit welcher MS-SQL Server Version haben Sie sich zuletzt davon überzeugt?
    Ab Version 2005 ist der Detailgrad der grafischen Ausgabe der Ausführungspläne sehr hoch. Mit der Version von 2008 bekommen Sie sogar zusätzlich noch Informationen angezeigt, welche Indizes fehlen. (Diese Satz war aber nicht an Sie gerichtet ;-) )
    Jedenfalls könnten Sie sehr einfach überprüfen, ob Ihr Wissen um die Brillianz des MS-SQL Optimizers nicht revidiert werden sollte...

    Viele Grüße
    Christoph Ingenhaag
    • 24 Oct 2008, 09:25 am
  • Post visible to registered members
  • Dirk Gunsthövel
    Dirk Gunsthövel    Premium Member
    The company name is only visible to registered members.
    Re^11: MySQL mehrere relationelle Tabellen in einem Query?
    Hallo,

    Christoph Ingenhaag schrieb:
    Hallo Herr Gunsthövel ,
    Ab Version 2005 ist der Detailgrad der grafischen Ausgabe der Ausführungspläne sehr hoch. Mit der Version von 2008 bekommen Sie sogar zusätzlich noch Informationen angezeigt, welche Indizes fehlen. (Diese Satz war aber nicht an Sie gerichtet ;-) )
    Jedenfalls könnten Sie sehr einfach überprüfen, ob Ihr Wissen um die Brillianz des MS-SQL Optimizers nicht revidiert werden sollte...
    Touché ;-)

    Mit V 2005 habe ich noch nicht getestet. In Versionen davor hatte ich
    massive und teils abenteuerliche Probleme mit Unions und darin
    enthaltenen offensichtlich (i.e. für mich aber nicht den optimizer)
    redundanten Zweigen.

    Grob vereinfacht sowas wie:

    SELECT
    bar FROM foo WHERE name LIKE 'G%'
    UNION
    SELECT
    bar FROM foo WHERE name LIKE 'Gu%'

    Ich bin zur Zeit auf Reisen aber vielleicht wären Sie bereit, mal ein
    Testskript laufen zu lassen (falls ich das wiederfinde, wenn ich
    zurück bin).

    Da fällt mir gerade ein:
    Wir haben zur Zeit einen schönen Kundenauftrag, wo es in step
    1 um die Auswahl eines DB-Systems für das Produkt geht und
    wir umfangreiche Tests machen werden. Kandidaten für den
    Vergleich sind im Moment auf Kundenwunsch Oracle, Informix,
    MySQL und PostgreSQL. Vielleicht hätten Sie Lust, das mit uns
    zusammen (ausser Konkurrenz) mal mit MS-SQL laufen zu
    lassen?

    Grundsätzlich fände ich es toll, wenn man sich gelegentlich
    austauschen könnte. Sie haben -schliesse ich mal - einen
    starken MS SQL Fokus, während wir ursprünglich aus der
    DB2/Informix Ecke kommen. Sie wissen wahrscheinlich wie
    ich, dass die Paradigmen in diesen Bereichen sehr unterschiedlich
    sind. Teilweise gestaltet sich ein Gedankenaustausch sehr
    schwierig, da man in beiden Bereichen sehr wenig Leute
    findet, die bereit und in der Lage sind, über den Tellerrand
    zu blicken.

    Übrigens erinnere ich mich an Ihr Posting, in dem Sie völlig
    richtig sagen, dass es für spezifische Fragen natürlich
    deutlich bessere Foren/Groups gibt als das hier. Ich finde
    trotzdem, dass im Kontext von "über den Tellerrand des
    eigenen Lieblingssystems hinaussehen" dieses Forum
    durchaus Potential haben könnte.

    Mit freundlichen Grüßen
    Dirk Gunsthövel
    • 24 Oct 2008, 11:45 am
  • Post visible to registered members
  • Christoph Ingenhaag
    Christoph Ingenhaag    Premium Member
    The company name is only visible to registered members.
    Re^12: MySQL mehrere relationelle Tabellen in einem Query?
    Karl Reitschuster schrieb:

    Einspruch ;-) Das Anzeigen von detailreichen execution plans bedeutet ja noch lange nicht dass es immer der effektivste ist - in unserem Fall der brillanteste ist; Den optimalen Plan zu finden ist wirklich das Kennzeichen eines guten Optimizers vorausgesetzt die Statistiken zu den Objekten sind vorhanden.
    Beste Grüsse
    Karl Reitschuster
    Einspruch abgelehnt ;-)
    Das habe ich nicht geschrieben, ich schrieb lediglich, dass man mit der detaillreichen Ausgabe des Ausführungsplans besser erkennen kann, welche Qualität der Plan hat (wenn man dies denn zu beurteilen vermag).
    Das kann ja theoretisch von grottenschlecht bis brilliant reichen.
    Ich stimme Ihnen also zu, nur der Bezug ist nicht gerechtfertigt ;-)

    Schönes Wochenende
    Christoph Ingenhaag
    • 24 Oct 2008, 2:18 pm
  • Christoph Ingenhaag
    Christoph Ingenhaag    Premium Member
    The company name is only visible to registered members.
    Re^12: MySQL mehrere relationelle Tabellen in einem Query?
    Dirk Gunsthövel schrieb:

    Ich bin zur Zeit auf Reisen aber vielleicht wären Sie bereit, mal ein
    Testskript laufen zu lassen (falls ich das wiederfinde, wenn ich
    zurück bin).
    Klar, gerne.

    Da fällt mir gerade ein:
    Wir haben zur Zeit einen schönen Kundenauftrag, wo es in step
    1 um die Auswahl eines DB-Systems für das Produkt geht und
    wir umfangreiche Tests machen werden. Kandidaten für den
    Vergleich sind im Moment auf Kundenwunsch Oracle, Informix,
    MySQL und PostgreSQL. Vielleicht hätten Sie Lust, das mit uns
    zusammen (ausser Konkurrenz) mal mit MS-SQL laufen zu
    lassen?
    Auf jeden Fall interessant! Momentan ist SQL Server ja dann hauptsächlich auf der Kundenwunschliste, wenn es um BI geht.

     
    Grundsätzlich fände ich es toll, wenn man sich gelegentlich
    austauschen könnte. Sie haben -schliesse ich mal - einen
    starken MS SQL Fokus, während wir ursprünglich aus der
    DB2/Informix Ecke kommen. Sie wissen wahrscheinlich wie
    ich, dass die Paradigmen in diesen Bereichen sehr unterschiedlich
    sind. Teilweise gestaltet sich ein Gedankenaustausch sehr
    schwierig, da man in beiden Bereichen sehr wenig Leute
    findet, die bereit und in der Lage sind, über den Tellerrand
    zu blicken.
    Ja, in der IT als moderne Religion auf mittelalterlichem Niveau mit ihren diversen Fanatikern Freigeister zu finden ist nicht einfach ;-)
    Über einen Austausch würde ich ich freuen!

    Übrigens erinnere ich mich an Ihr Posting, in dem Sie völlig
    richtig sagen, dass es für spezifische Fragen natürlich
    deutlich bessere Foren/Groups gibt als das hier. Ich finde
    trotzdem, dass im Kontext von "über den Tellerrand des
    eigenen Lieblingssystems hinaussehen" dieses Forum
    durchaus Potential haben könnte.
    Vollste Zustimmung.

    Schöne Wochenende
    Viele Grüße
    Christoph Ingenhaag
    • 24 Oct 2008, 2:31 pm
  • Christoph Ingenhaag
    Christoph Ingenhaag    Premium Member
    The company name is only visible to registered members.
    Re^12: MySQL mehrere relationelle Tabellen in einem Query?
    Mit V 2005 habe ich noch nicht getestet. In Versionen davor hatte ich
    massive und teils abenteuerliche Probleme mit Unions und darin
    enthaltenen offensichtlich (i.e. für mich aber nicht den optimizer)
    redundanten Zweigen.
    SQL Server 2005 und SQL Server 2008

    select LfdID, Vorname
    from Vornamensliste
    where Vorname like 'A%'
    union
    select LfdID, Vorname
    from Vornamensliste
    where Vorname like 'Au%'

    stark gekürzte Fassung:
    select
    --|--Stream Aggregate(GROUP BY:([Union1007], [Union1006]))
    -----|--Merge Join(Concatenation)
    ---------|--Index Seek(...)
    ---------|--Index Seek(...)

    Wo bei bei diesem äquivalenten Statement

    select LfdID, Vorname
    from Vornamensliste
    where
    Vorname like 'A%' or
    Vorname like 'Au%'

    die Überlappung zusammengefasst wird

    select
    --|--Index Seek(...)

    Und hier der Index Seek:
    Start Range: [TestDB].[dbo].[Vornamensliste].Vorname >= Scalar Operator('9þ'); End Range: [TestDB].[dbo].[Vornamensliste].Vorname < Scalar Operator('B')

    Wie machen das denn andere RDBMS?

    Viele Grüße
    Christoph Ingenhaag
    • 24 Oct 2008, 5:59 pm