Group by funktioniert nicht

[Bine]

Hallo!

Ich hab folgende Select-Anweisung, die mir zwei Datensätze aus meiner DB holt:

select tbl_100_00_id,wcost,wtsc from tbl_100_01 where tbl_100_00_id='22'

...Ich möchte nun erreichen, dass nur der Datensatz aus der DB geholt wird, bei dem wtsc maximal ist.

Ich habs schon mit:

select tbl_100_00_id,wcost,Max(wtsc) from tbl_100_01 where tbl_100_00_id='22' group by tbl_100_00_id

versucht, aber dann passiert etwas ganz seltsames. Ich bekomme dann zwar nur einen Datensatz und in diesem Datensatz ist wtsc auch maximal, aber die restlichen Spalten gehören eigentlich gar nicht zu dieser Zeile:

Beispiel:
tbl_100_00_id     wcost    wtsc
22                 0.00     2000-01-01
22                30.00     2003-01-01

mit group by erhalte ich dann:

22       0.00     2003-01-01

wie kann das sein und was stimmt an meiner group by abfrage nicht?
Bitte helft mir!

Vielen Dank!
Gruß Bine

[Cheatah]

Hi,

select tbl_100_00_id,wcost,Max(wtsc) from tbl_100_01 where tbl_100_00_id='22' group by tbl_100_00_id

SELECT spaltenliste, gruppenfunktionsliste FROM tabelle ... GROUP BY spaltenliste

Es ergibt nicht den geringsten Sinn, Spalten zu selektieren, nach denen man nicht gruppiert (sofern man gruppiert, versteht sich).

aber dann passiert etwas ganz seltsames.

Wenn Dein DBMS - welches immer das sein mag - keinen Fehler schmeißt, ist das in der Tat seltsam. MySQL tut solche Dinge.

Cheatah

[Bine]

Hi Cheatah,

aber wie kann ich das Problem denn dann lösen? Wie kann ich eine Zeile aus einer DAtenbank holen bei der ein bestimmter Wert maximal ist?

Gruß Bine

[Cheatah]

Hi,

aber wie kann ich das Problem denn dann lösen? Wie kann ich eine Zeile aus einer DAtenbank holen bei der ein bestimmter Wert maximal ist?

richtig gruppieren, sortieren und limitieren, oder mit Subselects arbeiten, falls Dein DBMS - welches immer das sein mag - dies beherrscht. Woher weißt Du (bzw. genauer: Dein DBMS) eigentlich, dass es nur _eine_ Zeile gibt, bei der ein bestimmter Wert maximal ist?

Cheatah

[Philipp Hasenfratz]

Halihallo Bine

...Ich möchte nun erreichen, dass nur der Datensatz aus der DB geholt wird, bei dem wtsc maximal ist.

Welche RDBMS verwendest du? - MySQL... höchst wahrscheinlich.

versucht, aber dann passiert etwas ganz seltsames. Ich bekomme dann zwar nur einen Datensatz und in diesem Datensatz ist wtsc auch maximal, aber die restlichen Spalten gehören eigentlich gar nicht zu dieser Zeile:

Nun, ein Bug oder Feature von MySQL. Wenn du nach tbl_100_00_id
gruppierst, müssen alle anderen Attribute ("Spalten") mit einer
Agregatsfunktion umschlossen werden (MIN,MAX,AVG,SUM,COUNT,...). Tust
du dies nicht, müsste der Query-Parser mit einer Fehlermeldung
abbrechen. MySQL tut dies leider nicht, die folge ist, dass MySQL
einfach und zufällig etwas auswählt.

Überlege mal: Du hast zwei Datensätze in tbl_100_00 mit der ID 22.
Du lässt wcost selektieren ohne Agregatsfunktion. Welches wcost von
den zwei Datensätzen soll denn nun verwendet werden? - Natürlich
wirst du mir jetzt antworten, dass dasjenige ausgewählt werden soll,
wo auch wtsc maximal ist. Nun, du irrst, denn sobald du gruppierst,
ist jedwelche Definition eines Datensatzes zerstört, du generierst
sozusagen einen neuen und dieser hat "zwei wcost". Was nun mit diesen
zwei wcost geschehen soll, um einen Wert daraus zu selektieren,
kannst du mit den genannten Agregatsfunktionen tun.

wie kann das sein und was stimmt an meiner group by abfrage nicht?

• Keine Agregatsfunktionen verwendet.
• Nach keinem eineindeutigen Attribut (z.B. PrimaryKey) gruppiert
    (dann ginge es nämlich).

Viele Grüsse

Philipp

[Bine]

Hallo Philipp,

Welche RDBMS verwendest du? - MySQL... höchst wahrscheinlich.

.. ja ich benutze MySQL, desewgen hab ich den Fehler auch nicht gleich entdeckt.
Danke für Deine Erklärungen... jetzt weiss ich zumindest wieso es nicht funktionert aber ich weiss immer noch nicht wie ich die Abfrage richtig machen kann.

• Keine Agregatsfunktionen verwendet.
• Nach keinem eineindeutigen Attribut (z.B. PrimaryKey) gruppiert
    (dann ginge es nämlich).

keine Agregatsfunktionen? Wie kann ich das ganze ohne MAX() machen? Wenn ich nach einem anderen Wert gruppiere, dann erhalte ich immer 2 Datensätze.

Bitte hilf mir!

Grüßle Bine

[Philipp Hasenfratz]

Halihallo Bine

.. ja ich benutze MySQL, desewgen hab ich den Fehler auch nicht gleich entdeckt.

Version?

keine Agregatsfunktionen? Wie kann ich das ganze ohne MAX() machen?

Eben nicht.

Wenn ich nach einem anderen Wert gruppiere, dann erhalte ich immer 2 Datensätze.

Rate nicht, wisse!

Erstens brauchst du ein vernünftiges Datenschema, denn deines ist
m.E. Schrott:

Entweder du hast einen Primary Key, dann ist der Name 'tbl_..._id'
irreführend und somit schlecht,
oder du hast keinen Primary Key und dann ist das Datenbankschema
Schrott und nicht sinnvoll zu verwenden.

Jeder Datensatz muss eineindeutig ansprechbar sein => Primary Key.
Ansonsten hast du keine Relation, sondern eine Tabelle und hättest
absolut keine Chance dieses Problem zu lösen (zumindest sehe ich
keine [gute]).

Also:
tbl_100_00

id           PRIMARY KEY, z.B. als AUTOINC
tbl_old_id   das ist die tbl_100_00_id.
wcost
wtsc

Möglichkeit 1:
MySQL>4.x:

SELECT tbl_old_id, wcost, wtsc
FROM tbl_100_00
WHERE
  id IN (
    SELECT id
    FROM tbl_100_00
    WHERE tbl_old_id=22
    GROUP BY wtsc DESC
    LIMIT 1
  )

Möglichkeit 2:
MySQL<4.x:

SELECT a1.tbl_old_id, a1.wtsc, MAX(a2.wcost)
FROM tbl_100_00 AS a1, tbl_100_00 AS a2
WHERE
  a1.id=a2.id AND
  a1.tbl_old_id=22 AND
GROUP BY a1.wtsc DESC
LIMIT 1

oder so ähnlich. Ohne Subselects ist das Leben schwer... Beachte,
dass dies keine gute Lösung ist, da es - wie Cheatah sagt - mehrere
Maximas geben kann und diese dann aussen vor gelassen werden.

Möglichkeit 3: zwei queries.

Tipp: Befasse dich mit relationaler Algebra und mache dich mit diesem
Denken vertraut.

Viele Grüsse

Philipp

[Bine]

Hallo Philipp;

Erstens brauchst du ein vernünftiges Datenschema, denn deines ist
m.E. Schrott:

..das Datenschema stammt nicht von mir... und ich kann es auch nicht ändern, sondern soll nur Abfragen durchführen. tbl_100_00_id und wtsc sind die Primärschlüssel, deswegen kann es auch nur zu jedem tbl_100_00_id ein Maxima geben.
Ich benutze MySQL<4.x, die genaue Version weiss ich gerade nicht. Subselects funktionieren auf jeden Fall nicht.

Ich hatte jetzt noch eine Idee:

select wcost,wtsc,tbl_100_00_id from tbl_100_01 where tbl_100_00_id='22' order by wtsc DESC limit 1

Diese Abfrage funktioniert... nur wie sieht es mit der Performance aus? Könnte ich das ganze so machen?

Grüße Bine

[Klaus Mock]

Hallo,

Ansonsten hast du keine Relation, sondern eine Tabelle und hättest
absolut keine Chance dieses Problem zu lösen (zumindest sehe ich
keine [gute]).

Wenn ich mich nicht ganz irre, hat man Relationen erst, wenn man mindestens zwei Tabellen hat, die miteinander in Beziehung stehen. Eine Tabelle für sich ist einfach nur eine Tabelle, egal ob mit oder ohne Primärschlüssel.

SELECT tbl_old_id, wcost, wtsc
FROM tbl_100_00
WHERE
  id IN (
    SELECT id
    FROM tbl_100_00
    WHERE tbl_old_id=22
    GROUP BY wtsc DESC
    LIMIT 1
  )

Du meinst wohl ORDER BY statt GROUP BY.

Es könnte auch so lauten

SELECT tbl_old_id, wcost, wtsc
  FROM tbl_100_00
 WHERE
   wtsc IN (
     SELECT max(wtsc)
       FROM tbl_100_00
      WHERE tbl_old_id=22
      )

SELECT a1.tbl_old_id, a1.wtsc, MAX(a2.wcost)
FROM tbl_100_00 AS a1, tbl_100_00 AS a2
WHERE
  a1.id=a2.id AND
  a1.tbl_old_id=22 AND
GROUP BY a1.wtsc DESC
LIMIT 1

Auch hier: Du meinst wohl ORDER BY statt GROUP BY.

Grüße
  Klaus

[Ilja]

yo,

Ansonsten hast du keine Relation, sondern eine Tabelle und hättest
absolut keine Chance dieses Problem zu lösen (zumindest sehe ich
keine [gute]).

Wenn ich mich nicht ganz irre, hat man Relationen erst, wenn man mindestens zwei Tabellen hat, die miteinander in Beziehung stehen. Eine Tabelle für sich ist einfach nur eine Tabelle, egal ob mit oder ohne Primärschlüssel.

eine relation ist in der datenbank-sprache ein anderes wort für tabelle. realtionship ist eine beziehung.

Ilja

[Philipp Hasenfratz]

Halihallo Ilja

Wenn ich mich nicht ganz irre, hat man Relationen erst, wenn man mindestens zwei Tabellen hat, die miteinander in Beziehung stehen. Eine Tabelle für sich ist einfach nur eine Tabelle, egal ob mit oder ohne Primärschlüssel.

eine relation ist in der datenbank-sprache ein anderes wort für tabelle. realtionship ist eine beziehung.

Nun, es gibt eben doch einen Unterschied zwischen Tabelle und
Relation. Sagen wir es mal so: Jede Relation ist eine Tabelle, aber
nicht jede Tabelle ist eine Relation. Ich habe es dahingehend
interpretiert, dass eine Relation eine Tabelle mit PRIMARY und
optinal FOREIGN KEY(s) ist (welche die Grundlage für Beziehungen
sind) und Klaus ging in der Begründung noch tiefer und sagte,
dass die PRIMARY und FOREIGN KEY(s) für eine Relation nicht nur
definiert, sondern auch für eine Relationship benutzt werden müssen
und ich bin geneigt ihm recht zu geben. Nun, man kann natürlich auch
eine Beziehung über nicht PRIMARY/FOREIGN-Keys herstellen und dann
wäre die Schlussfolgerung richtig, dass beide Begriffe als Synonym
verwendet werden dürfen, aber die Theorie sieht es eigentlich schon
anders vor :-)

Nun, beide Begriffe einfach als Synonym zu behandeln halte ich für
etwas verharmlosend :-) Oder soll jetzt Excel auch als Datenbank
gewertet werden? - Access ist schon schlimm genug :-)

Viele Grüsse

Philipp

[Axel Richter]

Hallo,

Nun, es gibt eben doch einen Unterschied zwischen Tabelle und
Relation. Sagen wir es mal so: Jede Relation ist eine Tabelle, aber
nicht jede Tabelle ist eine Relation.

Ja, jede Tabelle in einer relationalen Datenbank ist, mathematisch betrachtet, eine spezielle Form der Menge, eine Relation. Eine beliebige Ansammlung von Daten in Zeilen und Spalten ist keine Relation, speziell dann nicht, wenn in Spalten Daten unterschiedlichen Typs untereinander stehen können.

Das ist eine Relation:
Beispiel1:
ID Name   Vorname  Geburtsdatum  Gehalt
01 Maier  Klaus    23.07.1978    2.678,89 EUR
02 Anders Marie    03.11.1969    3.477,90 EUR
....

Darin sind ID, Name, Vorname, Geburtsdatum und Gehalt Spalten bzw. Felder oder, mathematisch betrachtet, Attribute. Jedes Attribut kann _nur_ Attributwerte _eines_ definierten Typs annehmen.

Die Zeilen sind Datensätze oder, mathematisch betrachtet, Tupels.

Das ist keine Relation:
Beispiel2:
Spalte1 Spalte2  Spalte3    Spalte4
Rechnung

Herrn
Klaus Maier
Feldweg 23
04567 Testort

Pos     Artikel  Menge      Preis
1       Hose     5          34,67
2       Jacke    2          45,78

Oder soll jetzt Excel auch als Datenbank
gewertet werden?

Nun, da man mit Excel sowohl Beispiel1 als auch Beispiel2 abbilden kann, _kann_ Excel auch eine Datenbank sein.

Access ist schon schlimm genug :-)

Warum?
[] Weil es von Microsoft ist.
[] Weil ich es nicht kenne bzw. beherrsche.
[] Aus folgenden, mir wichtigen Gründen:

viele Grüße

Axel

[Philipp Hasenfratz]

Halihallo Axel

Ja, jede Tabelle in einer relationalen Datenbank ist, mathematisch betrachtet, eine spezielle Form der Menge, eine Relation. Eine beliebige Ansammlung von Daten in Zeilen und Spalten ist keine Relation, speziell dann nicht, wenn in Spalten Daten unterschiedlichen Typs untereinander stehen können.

Dann ist also deiner Meinung nach auch jede Datebanktabelle eine
Relation, denn nach 1NF und CREATE TABLE-Möglichkeiten bestünde
keine Möglichkeit eine Tabelle so zu erstellen, dass es keine
Relation nach deiner Definition ist.

Das ist eine Relation:

Hm. Deine Definition. Ich bin damit nicht wirklich einverstanden, da
sie nicht impliziert eine Relationship mit einer anderen Tabelle auf-
zubauen, oder zumindest die Grundvoraussetzung dafür zu erfüllen.
Es sei denn, du definierst ID ausdrücklich als PRIMARY KEY, dann
wäre ich einverstanden.

Darin sind ID, Name, Vorname, Geburtsdatum und Gehalt Spalten bzw. Felder oder, mathematisch betrachtet, Attribute. Jedes Attribut kann _nur_ Attributwerte _eines_ definierten Typs annehmen.

Nein, mathematisch betrachtet sind Attribute Elemente einer Menge
und die Daten einer Tabelle ist eine Multimenge (und deshalb per
Definition unsortiert, was einigen Anfängern gerne zum Verhängnis
wird :-)).

Das ist keine Relation:
Beispiel2:
Spalte1 Spalte2  Spalte3    Spalte4
Rechnung

Herrn
Klaus Maier
Feldweg 23
04567 Testort

Pos     Artikel  Menge      Preis
1       Hose     5          34,67
2       Jacke    2          45,78

Full ACK.

Oder soll jetzt Excel auch als Datenbank
gewertet werden?
Nun, da man mit Excel sowohl Beispiel1 als auch Beispiel2 abbilden kann, _kann_ Excel auch eine Datenbank sein.

Na, meinetwegen, es gibt ja eine ODBC-Schnittstelle zu Excel ;-)

Access ist schon schlimm genug :-)
Warum?
[X/4] Weil es von Microsoft ist.
[X/4] Weil ich es nicht kenne bzw. beherrsche.

Ich kenne es nicht gut, habe aber schon damit gearbeitet.

[X/2] Aus folgenden, mir wichtigen Gründen:

Access wiederspiegelt einen meiner Meinung nach typischen
konzeptionellen Fehler von Microsoft. Sie vermischen verschiedene
Abstraktionsgrade (Darstellung/Formular - Datenebene) vermeindlich
zu Gunsten von Endanwendern und Otto-Normal-Usern. Ein
Datenbanksystem sollte in sich geschlossen sein und nichts mit der
Anwenderebene zu tun haben, mehr noch: selbst der Zugriff auf die
Datenbank (über connect zu query-parser) sollte von den internas
(table handler) getrennt sein. MS SQL-Server ist hier schon sehr gut
zu gebrauchen.

Viele Grüsse

Philipp

[Axel Richter]

Hallo Philipp,

Hm. Deine Definition. Ich bin damit nicht wirklich einverstanden, da
sie nicht impliziert eine Relationship mit einer anderen Tabelle auf-
zubauen, oder zumindest die Grundvoraussetzung dafür zu erfüllen.

Doch, jede Tabelle, welche sich an die Definition hält, also jede Datenbanktabelle, erfüllt die Grundvoraussetzungen für eine Beziehung zu einer anderen Datenbanktabelle. Eine Beziehung definiert sich von Attribut einer Relation zu Attribut einer zweiten Relation. Einzige Voraussetzung hierfür ist, dass beide Attribute Attribute des selben Typs sind oder zumindest in einen Typ überführt werden können.

Es sei denn, du definierst ID ausdrücklich als PRIMARY KEY, dann
wäre ich einverstanden.

Es ist nicht zwingend ein Primary Key an einer Beziehung beteiligt. Es kann auch n:m - Beziehungen geben.

Nein, mathematisch betrachtet sind Attribute Elemente einer Menge
und die Daten einer Tabelle ist eine Multimenge (und deshalb per
Definition unsortiert, was einigen Anfängern gerne zum Verhängnis
wird :-)).

Attribute(Felder) sind Elemente der Menge Tupel(Datensatz). Tupels(Datensätze) sind Elemente der Menge Relation(Datenbanktabelle). Somit ist eine Datenbanktabelle eine Menge von Mengen, eine Multimenge. So habe ich das, glaube ich, schon beschrieben.

Access ist schon schlimm genug :-)
Warum?
[X/4] Weil es von Microsoft ist.
[X/4] Weil ich es nicht kenne bzw. beherrsche.
Ich kenne es nicht gut, habe aber schon damit gearbeitet.
[X/2] Aus folgenden, mir wichtigen Gründen:
Access wiederspiegelt einen meiner Meinung nach typischen
konzeptionellen Fehler von Microsoft. Sie vermischen verschiedene
Abstraktionsgrade (Darstellung/Formular - Datenebene) vermeindlich
zu Gunsten von Endanwendern und Otto-Normal-Usern.

Darin kann ich keinen Nachteil sehen. Tabellen und gespeicherte Abfragen _sind_ von Formularen und Berichten getrennt. Die Möglichkeit, Formulare und Berichte zu erstellen, bieten das, was Access eben sein soll, ein RDBMS mit Office-Benutzerschnittstelle. Man muss diese Schnittstelle nicht nutzen. Meiner Meinung nach, fehlt aber genau diese Möglichkeit im OpenOffice noch. Wobei man natürlich auch dort Tabellendokumente mit externen Datenbanken verbinden kann, allerdings lange nicht so komfortabel, wie mit Access im MS-Office. Der _normale_ Office-Nutzer verlässt sich zwar meist auf einen Datenbankadministrator. Ich kenne aber mehrere Anwender, die sich einen solchen nicht leisten können/wollen.

Ein Datenbanksystem sollte in sich geschlossen sein und nichts mit der
Anwenderebene zu tun haben, mehr noch: selbst der Zugriff auf die
Datenbank (über connect zu query-parser) sollte von den internas
(table handler) getrennt sein. MS SQL-Server ist hier schon sehr gut
zu gebrauchen.

Wie gesagt, man kann Access genau so verwenden. Man schreibt einfach nur Tabellen und Abfragen im Access und nutzt andere Office-Anwendungen oder Programmiersprachen um via ODBC mit SQL darauf zuzugreifen.

Es _gibt_ Nachteile. Die größten sind dadurch begründet, dass die Access DB _eine_ Datei im Filesystem ist. Zugriffsberechtigungen des Filesystems können also nur auf die gesamte Datenbank angewendet werden. Access bietet zwar auch eine interne Benutzerverwaltung, die sich aber leider auch bei den neueren Versionen noch nicht mit der des Betriebssystems verbinden lässt. Außerdem wird durch diese eine, schnell mehrere MByte gross werdende, Datei auch die Replikation zwischen unterschiedlichen WAN-Standorten schnell sehr zeitaufwändig.

viele Grüße

Axel

[Philipp Hasenfratz]

Halihallo Axel

Hm. Deine Definition. Ich bin damit nicht wirklich einverstanden, da
sie nicht impliziert eine Relationship mit einer anderen Tabelle auf-
zubauen, oder zumindest die Grundvoraussetzung dafür zu erfüllen.
Doch, jede Tabelle, welche sich an die Definition hält, also jede Datenbanktabelle, erfüllt die Grundvoraussetzungen für eine Beziehung zu einer anderen Datenbanktabelle. Eine Beziehung definiert sich von Attribut einer Relation zu Attribut einer zweiten Relation. Einzige Voraussetzung hierfür ist, dass beide Attribute Attribute des selben Typs sind oder zumindest in einen Typ überführt werden können.

Zugestanden. Beziehungen lassen sich auch über nicht ausdrücklich
dafür bestimmte Attribute herstellen, jedoch ist dies in der
Theorie - wie ich schoneinmal bemerkte - *nicht umbedingt*
vorgesehen.

Zurück zur Definition. Eine Relation ist im mathematischen Sinne eine
Zuordnung von Elementen aus einer oder mehreren Mengen und ist eine
Teilmenge des kartesischen Produktes dieser Mengen. Praktisch lässt
sich dieses kartesische Produkt natürlich durch irgendeine Join-
Bedingung einschränken, theoretisch ist es jedoch vorgeschlagen die
Bedingungen über (Fremd-)Schlüssel im Datenschema zu definieren.

Und in der Tat: Du musst diese (im mathematischen Sinne) Relation
irgendwie ausdrücken|definieren (falls denn eine Tabelle eine
Relation sein soll) und dies geschieht über Primary und Foreign Keys.

Nehmen wir mal folgendes:

Person

person_id     PRIMARY KEY
adresse_id    FOREIGN KEY
name

Adresse

adresse_id    PRIMARY KEY
name

Diese zwei Tabellen definieren die mathematische Relation:

R = {(person_id,adresse_id) | durch Inhalt bestimmt}

oder konkret z.B.:

R = {(1,15),(2,13),(3,15)};  // Adresse 15 beherbergt zwei Personen,
                             // die Personen 1 und 3.

Durch PRIMARY und FOREIGN KEY in Person ist diese Relation bereits
vollständig definiert und deshalb ist meiner Meinung nach Person
eine Relation (nicht nur eine Tabelle). Adresse selber ist auch
eine Relation, nämlich die Identitsche => jeder PRIMARY KEY wird auf
sich selber abgebildet.
Ohne PRIMARY und FOREIGN KEY liesse sich eine Relation nur dynamisch
durch eine SQL-Abfrage definieren, die Tabelle selber ist jedoch
keine Relation! - Erst die Ausführung des Queries generiert dynamisch
eine Relation.

Es sei denn, du definierst ID ausdrücklich als PRIMARY KEY, dann
wäre ich einverstanden.
Es ist nicht zwingend ein Primary Key an einer Beziehung beteiligt. Es kann auch n:m - Beziehungen geben.

n:m Beziehungen werden in der Theorie durch eine dritte Tabelle
gelöst, welche jeweils von jeder der zwei Tabellen den Primary Key
nimmt. Aber auch hier kannst du die Relation natürlich dynamisch
über die Attribute erstellen, aber wozu bräuchtest du denn noch
Primary und Foreign Keys?
Zugestanden, es ist nicht immer ein primary key an der Beziehung
beteiligt, aber falls dem so ist, sind diese Tabellen
keine Relationen, sondern es sind lediglich Tabellen, über die du
mit einer geeigneten Join-Bedingung dynamisch und "temporär" eine
Relation definierst.

Access ist schon schlimm genug :-)
Warum?
[X/4] Weil es von Microsoft ist.
[X/4] Weil ich es nicht kenne bzw. beherrsche.
Ich kenne es nicht gut, habe aber schon damit gearbeitet.
[X/2] Aus folgenden, mir wichtigen Gründen:
Access wiederspiegelt einen meiner Meinung nach typischen
konzeptionellen Fehler von Microsoft. Sie vermischen verschiedene
Abstraktionsgrade (Darstellung/Formular - Datenebene) vermeindlich
zu Gunsten von Endanwendern und Otto-Normal-Usern.
Darin kann ich keinen Nachteil sehen. Tabellen und gespeicherte Abfragen _sind_ von Formularen und Berichten getrennt. Die Möglichkeit, Formulare und Berichte zu erstellen, bieten das, was Access eben sein soll, ein RDBMS mit Office-Benutzerschnittstelle. Man muss diese Schnittstelle nicht nutzen. Meiner Meinung nach, fehlt aber genau diese Möglichkeit im OpenOffice noch. Wobei man natürlich auch dort Tabellendokumente mit externen Datenbanken verbinden kann, allerdings lange nicht so komfortabel, wie mit Access im MS-Office. Der _normale_ Office-Nutzer verlässt sich zwar meist auf einen Datenbankadministrator. Ich kenne aber mehrere Anwender, die sich einen solchen nicht leisten können/wollen.

Naja, einverstanden :-)

Viele Grüsse

Philipp

[Jörg Lorenz]

Hallo,

Oder soll jetzt Excel auch als Datenbank
gewertet werden?
Nun, da man mit Excel sowohl Beispiel1 als auch Beispiel2 abbilden kann, _kann_ Excel auch eine Datenbank sein.

Na, meinetwegen, es gibt ja eine ODBC-Schnittstelle zu Excel ;-)

, die man aber nicht braucht. Excel ist nur eine Anwendung, aber man kann mit Excel wunderbar Datenbanken erstellen und verwalten.

Beispiel Hotel:

• Lieferanten
• deren Artikel in Gruppen und Untergruppen
• Kostenstellen des Hotels
• Bestellungen
• u. v. m.

Der Anwender arbeitet dabei nicht mal in den Tabellen, sondern in einer extra gestalteten Oberfläche.

Das läßt sich alles in Excel machen, aber viele User denken, Excel würde nur aus Tabellen und Diagrammen bestehen und daß man vielleicht ein paar Formeln eingeben könne. Aber: Stichwort VBA.

Viele Grüße

Jörg

[Philipp Hasenfratz]

Halihallo Jörg

Oder soll jetzt Excel auch als Datenbank
gewertet werden?
Nun, da man mit Excel sowohl Beispiel1 als auch Beispiel2 abbilden kann, _kann_ Excel auch eine Datenbank sein.

Na, meinetwegen, es gibt ja eine ODBC-Schnittstelle zu Excel ;-)

, die man aber nicht braucht.

Wie greifst du von einem selbstgeschriebenen Programm darauf zu? OK.
OLE/COM ist natürlich auch schön :-)

Excel ist nur eine Anwendung, aber man kann mit Excel wunderbar Datenbanken erstellen und verwalten.

Zugestanden und wie gesagt auch meinetwegen. Ich kann auch mit
Notepad eine Datenbank erstellen... Aber man sollte vielleicht einmal
die 12 goldenen Regeln von Codd lesen um zu wissen, was eine
Datenbank so alles leisten _sollte_. Ja, ich weiss, das ist nicht die
Definition einer Datenbank.

Beispiel Hotel:

• Lieferanten
• deren Artikel in Gruppen und Untergruppen
• Kostenstellen des Hotels
• Bestellungen
• u. v. m.

Wow, das ist ja krass, was man alles in Excel schreiben kann...

Der Anwender arbeitet dabei nicht mal in den Tabellen, sondern in einer extra gestalteten Oberfläche.
Das läßt sich alles in Excel machen, aber viele User denken, Excel würde nur aus Tabellen und Diagrammen bestehen und daß man vielleicht ein paar Formeln eingeben könne. Aber: Stichwort VBA.

Das ist ja alles schön und gut und mir sogar durchaus bekannt. Nur
spricht das herzlich wenig für eine Datenbank.

Viele Grüsse

Philipp

[Jörg Lorenz]

Hi,

ohne jetzt groß diskutieren zu wollen - der Feierabend naht:

Na, meinetwegen, es gibt ja eine ODBC-Schnittstelle zu Excel ;-)

, die man aber nicht braucht.

Wie greifst du von einem selbstgeschriebenen Programm darauf zu? OK.
OLE/COM ist natürlich auch schön :-)

Man kann auch diverse Bordmittel verwenden, die Excel bereits mitbringt.

Zugestanden und wie gesagt auch meinetwegen. Ich kann auch mit
Notepad eine Datenbank erstellen... Aber man sollte vielleicht einmal
die 12 goldenen Regeln von Codd lesen um zu wissen, was eine
Datenbank so alles leisten _sollte_. Ja, ich weiss, das ist nicht die
Definition einer Datenbank.

Eigentlich sind es 13 Regeln. Die kann man mit Excel verwirklichen. Ja, ich weiß, Excel ist dafür nicht vorgesehen, aber es geht. Man muß nur Alt + F11 drücken und wissen, was man wo eingeben muß ;-)

Viele Grüße und einen schönen Abend

Jörg

[Philipp Hasenfratz]

Halihallo Jörg

ohne jetzt groß diskutieren zu wollen - der Feierabend naht:

Na, ja, ich hab heute auch genug diskutiert :-)

Wie greifst du von einem selbstgeschriebenen Programm darauf zu? OK.
OLE/COM ist natürlich auch schön :-)

Man kann auch diverse Bordmittel verwenden, die Excel bereits mitbringt.

VBA meinst du? - Naja, klar geht das.

Eigentlich sind es 13 Regeln.

Die goldene Regel 0. Richtig :-)

Die kann man mit Excel verwirklichen. Ja, ich weiß, Excel ist dafür nicht vorgesehen, aber es geht. Man muß nur Alt + F11 drücken und wissen, was man wo eingeben muß ;-)

Na, das ist ja wirklich eine feine Antwort und du hast damit auch
absolut recht. Programmieren muss man halt können :-)

Viele Grüsse

Philipp

[Klaus Mock]

Hallo,

keine Agregatsfunktionen? Wie kann ich das ganze ohne MAX() machen? Wenn ich nach einem anderen Wert gruppiere, dann erhalte ich immer 2 Datensätze.

Ohne Subselects könnte das eventuell so gehen:

• Selektiere alle Daten, die Deinem Kriterium entsprechen ( tbl_100_00_id='22')[1]
• sortiere das Ergebnis absteigend nach der gewünschten Spalte (wtsc)
• lese nur den ersten Datensatz [2], eventuell unter Verwendung von LIMIT

Grüße
  Klaus

[1] wobei... wenn tbl_100_00_id eine numerische Spalte ist, sollte es eigentlich  tbl_100_00_id=22 lauten, weil dadurch unnötiges und eventuell fehleranfälliges Casting vermieden wird. Das aber nur am Rande.

[2] Natürlich nur unter der Einschränkung, das nur ein Datensatz den maximalen Wert von wtsc besitzt. siehe auch den Einwurf von Cheatah.

[Bine]

Hallo Klaus,

danke schön für Deinen Beitrag.

Ich werde es nach Deinem Entwurf machen.

Vielen DAnk und liebe Grüße.

Bine

[Axel Richter]

Hallo,

Nun, ein Bug oder Feature von MySQL. Wenn du nach tbl_100_00_id
gruppierst, müssen alle anderen Attribute ("Spalten") mit einer
Agregatsfunktion umschlossen werden (MIN,MAX,AVG,SUM,COUNT,...). Tust
du dies nicht, müsste der Query-Parser mit einer Fehlermeldung
abbrechen. MySQL tut dies leider nicht, die folge ist, dass MySQL
einfach und zufällig etwas auswählt.

Nein. Es nimmt den Wert aus dem _ersten_ Datensatz, der Datensatzgruppe, die in der Gruppierung zusammengefasst wird. Einige DBMS kennen hierfür die Agregatfunktion FIRST. Analog dazu gibt es dann meist auch LAST.

viele Grüße

Axel

[Cheatah]

Hi,

die folge ist, dass MySQL
einfach und zufällig etwas auswählt.
Nein. Es nimmt den Wert aus dem _ersten_ Datensatz, der Datensatzgruppe, die in der Gruppierung zusammengefasst wird.

wo ist der Unterschied zwischen dem ersten Datensatz einer unsortierten Gruppe und einer zufälligen Auswahl?

Cheatah

[Axel Richter]

Hallo,

wo ist der Unterschied zwischen dem ersten Datensatz einer unsortierten Gruppe und einer zufälligen Auswahl?

Es gibt keinen, solange es sich um eine unsortierte Gruppe handelt, was aber nicht immer der Fall sein muss.

viele Grüße

Axel