Doppelte Einträge

[shtml08]

Hallo!

Ich verzweifel gerade an eine Sortierung meiner sehr langen Tabelle mittels SQL (unten beispielhaft angeführt)
Diese soll so angezeigt werden, dass beim jeweiligen BONARTIKEL_BON
keine doppelte BONARTIKEL_EAN vorhanden ist.
So soll z.B. bei BONARTIKEL_BON 4 die EAN 666655554444 nicht zwei mal, sondern nur einmal im Eintrag 4 auftauchen (bei den anderen BONARTIKEL_BON-Einträgen wo diese EAN auftaucht, soll diese natürlich weiterhin, jedoch auch nur einmal, vohanden sein). Durch DISTINCT werden ALLE doppelten Einträge entfernt, was mir so nicht weiterhilft. Hat jemand eine Lösung?-Ich denke dass man eine verschachtelte Abfrage machen muss, komme aber leider auf keine Lösung.

Schönen Gruß!
Daniel

BONARTIKEL_BON|BONARTIKEL_EAN
2              222233334444
2              111155556666
2              222233334444
3              777788889999
4              666655554444
4              666655554444
4              222233334444

[ChrisB]

Hi,

Ich verzweifel gerade an eine Sortierung meiner sehr langen Tabelle mittels SQL (unten beispielhaft angeführt)

Das ist kein Problem der Sortierung, sondern der Selektion.

Diese soll so angezeigt werden, dass beim jeweiligen BONARTIKEL_BON
keine doppelte BONARTIKEL_EAN vorhanden ist.
So soll z.B. bei BONARTIKEL_BON 4 die EAN 666655554444 nicht zwei mal, sondern nur einmal im Eintrag 4 auftauchen (bei den anderen BONARTIKEL_BON-Einträgen wo diese EAN auftaucht, soll diese natürlich weiterhin, jedoch auch nur einmal, vohanden sein). Durch DISTINCT werden ALLE doppelten Einträge entfernt, was mir so nicht weiterhilft.

Moechtest du vielleicht nach Bon und EAN gruppieren?

MfG ChrisB

[shtml08]

Ja, oder der Selektion ;-)
Ich möchte die Werte so aufgelistet haben, dass keine doppelten EAN-Einträge bei der jeweiligen BON# vorhanden sind.
Durch eine Gruppierung verschwinden diese EInträge ja nicht.
Da ich den EAN's Namen zuordnen muss/will, wäre es alleine deshalb sinnvoll die Tabelle so zu verkleinern.

MfG

Daniel

[Rouven]

Hello,

Durch eine Gruppierung verschwinden diese EInträge ja nicht.

wieso nicht? sind sie nicht gleich? Wenn nein, nach welchem Kriterium wird "der eine" ausgewählt?

MfG
Rouven

[shtml08]

Hello,

Durch eine Gruppierung verschwinden diese EInträge ja nicht.
wieso nicht? sind sie nicht gleich? Wenn nein, nach welchem Kriterium wird "der eine" ausgewählt?

Okay, ihr habt recht. Mit GROUP BY müssten diese dann verschwinden. Jedoch ist mir trotzdem schleierhaft, wie ich das angehen soll.

[ChrisB]

Hi,

Okay, ihr habt recht. Mit GROUP BY müssten diese dann verschwinden. Jedoch ist mir trotzdem schleierhaft, wie ich das angehen soll.

Du weisst, wo nach du gruppieren willst, also gruppierst du danach - was ist denn daran jetzt noch Schleiereule?

MfG ChrisB

[shtml08]

OKAY, danke für Eure Hilfe.
Habe es durch

SELECT * FROM BONS_BONARTIKEL GROUP BY BON_NUMMER, BONARTIKEL_BON, BONARTIKEL_EAN

nun endlich hinbekommen.

MFG und schönen Tag noch!

Daniel

[Rouven]

Hello,

SELECT * FROM BONS_BONARTIKEL GROUP BY BON_NUMMER, BONARTIKEL_BON, BONARTIKEL_EAN

NEEEEEEEIIIIIIIIIIIIIIINNNNNNNN!!!

Bitte lies die Diskussion und eine Ausführungen zu den selektierten Spalten und GROUP BY.

MfG
Rouven

[shtml08]

Hello,

SELECT * FROM BONS_BONARTIKEL GROUP BY BON_NUMMER, BONARTIKEL_BON, BONARTIKEL_EAN
NEEEEEEEIIIIIIIIIIIIIIINNNNNNNN!!!

Bitte lies die Diskussion und eine Ausführungen zu den selektierten Spalten und GROUP BY.

Hey Rouven,

verstehe nicht so ganz warum meine Abfrage nun falsch ist.-Auch aus dem anderen Thread nicht so ganz ersichtlich.

[EKKi]

Mahlzeit shtml08,

verstehe nicht so ganz warum meine Abfrage nun falsch ist.-Auch aus dem anderen Thread nicht so ganz ersichtlich.

Du selektierst Felder, nach denen Du nicht gruppierst und die auch nicht durch eine Gruppierungs- oder Aggregatsfunktion behandelt werden. Jedes vernünftige Datenbanksystem würde Dir die Abfrage links und rechts um die Ohren hauen.

Vorsintflutliche MySQL-Versionen (welche nutzt Du?) leiden leider unter akuter Microsoftitis Browseriensis ... sie sind bei Fehler viel zu nachgiebig, raten herum, was der Benutzer wohl meinen könnte und präsentieren ihm dann irgendein Ergebnis (das meistens durch Zufall sogar ansatzweise stimmt).

MfG,
EKKi

[shtml08]

Hi EKKi

Du selektierst Felder, nach denen Du nicht gruppierst und die auch nicht durch eine Gruppierungs- oder Aggregatsfunktion behandelt werden. Jedes vernünftige Datenbanksystem würde Dir die Abfrage links und rechts um die Ohren hauen.

Na und wie soll ich die Gruppierung oder Aggregation anstellen?
Kann doch eigentlich nicht so schwer sein, die Abfrage zu generieren die ich eigentlich haben möchte...!?

Vorsintflutliche MySQL-Versionen (welche nutzt Du?) leiden leider unter akuter Microsoftitis Browseriensis ... sie sind bei Fehler viel zu nachgiebig, raten herum, was der Benutzer wohl meinen könnte und präsentieren ihm dann irgendein Ergebnis (das meistens durch Zufall sogar ansatzweise stimmt).

Nutze den Advantage Data Architect!

MfG

Daniel

[Ilja]

yo,

Kann doch eigentlich nicht so schwer sein, die Abfrage zu generieren die ich eigentlich haben möchte...!?

für dich werden wohl korrelierte unterabfragen die bessere wahl sein.

Ilja

[shtml08]

@ALL

Wie sieht es denn mit dem Befehl

SELECT BON_NUMMER, BONARTIKEL_EAN FROM XY

aus?

[shtml08]

Sorry, ich meinte:

SELECT DISTINCT BON_NUMMER, BONARTIKEL_EAN FROM XY

[EKKi]

Mahlzeit shtml08,

SELECT DISTINCT BON_NUMMER, BONARTIKEL_EAN FROM XY

Probier's aus ...

MfG,
EKKi

[EKKi]

Mahlzeit shtml08,

Na und wie soll ich die Gruppierung oder Aggregation anstellen?

Indem Du geeignete Gruppierungs- oder Aggregatsfunktion benutzt. Da Du bisher nicht Dein verwendetes Datenbanksystem und dessen Version angegeben hast, können Deine Leser im Prinzip nur MySQL spielen und raten ... und deswegen rate ich auch mal genau das: http://dev.mysql.com/doc/refman/5.1/de/group-by-functions-and-modifiers.html

Kann doch eigentlich nicht so schwer sein, die Abfrage zu generieren die ich eigentlich haben möchte...!?

Ist es auch nicht. Tu's doch einfach. Oder erwartest Du ernsthaft, dass sich irgendjemand aufgrund Deiner spärlichen Angaben hinsetzt und Deinen Job macht? Dann solltest Du Dir ein anderes Forum suchen ... dies hier heißt nicht ohne Grund "SELF"HTML.

Nutze den Advantage Data Architect!

Ist das jetzt eine Aufforderung an mich (wieso?) oder eine Aussage über Dich? Wenn letzteres, dann ist der wohl nicht besonders vorteilhaft.

MfG,
EKKi

[shtml08]

HI

Ist es auch nicht. Tu's doch einfach. Oder erwartest Du ernsthaft, dass sich irgendjemand aufgrund Deiner spärlichen Angaben hinsetzt und Deinen Job macht? Dann solltest Du Dir ein anderes Forum suchen ... dies hier heißt nicht ohne Grund "SELF"HTML.

Um Gottes Willen- Entschuldige wenn das so rübergekommen ist.
Ich bemühe mich schon darum, aber weis nicht so recht wie ich es angehen soll.

Ist das jetzt eine Aufforderung an mich (wieso?) oder eine Aussage über Dich? Wenn letzteres, dann ist der wohl nicht besonders

Weder das eine noch das Andere- ich dachte damit ist einigermaßen gesagt welches SQL ich nutze. Leider habe ich keine genaueren Infos darüber. Dort ist nur ersichtlich, dass es NativeSQL ist.

MfG

Daniel

[EKKi]

Mahlzeit shtml08,

Um Gottes Willen- Entschuldige wenn das so rübergekommen ist.
Ich bemühe mich schon darum, aber weis nicht so recht wie ich es angehen soll.

Nimm das Handbuch (oder alternativ die Online-Dokumentation) Deines Datenbanksystems zur Hand und informiere Dich zum Thema GROUP BY und den dezu gehörenden Gruppierungs- und Aggregationsfunktionen. Versuche, die dort hoffentlich vorhandenen Beispiele zu verstehen und auf Dein Anliegen anzuwenden. Wenn's nicht funktioniert, beschreibe Dein konkretes Problem und eventuelle Fehlermeldungen hier.

Weder das eine noch das Andere- ich dachte damit ist einigermaßen gesagt welches SQL ich nutze. Leider habe ich keine genaueren Infos darüber. Dort ist nur ersichtlich, dass es NativeSQL ist.

Du nutzt SAP?

MfG,
EKKi

[at]

Hallo.

Du nutzt SAP?

Kaum.
MfG, at

[Ilja]

yo,

dies hier heißt nicht ohne Grund "SELF"HTML.

solch einen satz habe ich hier schon lange nicht mehr gesehen...aber wenn man schon beim wortspiel ist, er hat ja keine frage zu HTML, sondern SQL.

Ilja

[Rouven]

Hello,

Du selektierst Felder, nach denen Du nicht gruppierst und die auch nicht durch eine Gruppierungs- oder Aggregatsfunktion behandelt werden.

das vermute ich, oder ist "*" zufällig das selbe wie "BON_NUMMER, BONARTIKEL_BON, BONARTIKEL_EAN" - wenn ja, dann schreibe es bitte hin (Warum soll ich nicht SELECT * schreiben)

Vorsintflutliche MySQL-Versionen (welche nutzt Du?) leiden leider unter akuter Microsoftitis Browseriensis ... sie sind bei Fehler viel zu nachgiebig, raten herum [...]

nicht nur vorsintflutliche - MySQL betrachtet die GROUP-BY-Funktionalität als ein besonderes Komfortfeature: GROUP BY hidden fields

MfG
Rouven

[EKKi]

Mahlzeit Rouven,

Du selektierst Felder, nach denen Du nicht gruppierst und die auch nicht durch eine Gruppierungs- oder Aggregatsfunktion behandelt werden.
das vermute ich, oder ist "*" zufällig das selbe wie "BON_NUMMER, BONARTIKEL_BON, BONARTIKEL_EAN" - wenn ja, dann schreibe es bitte hin (Warum soll ich nicht SELECT * schreiben)

Du meinst sicher shtml08 und nicht mich ...

MfG,
EKKi

[dedlfix]

echo $begrüßung;

Das vehemente Ablehnen von "SELECT *" und das MySQL-Bashing beim Selektieren nicht gruppierter Spalten ist in meinen Augen ein überflüssiger Volkssport. Beide Themen haben nicht nur Nachteile und oft sind sie nicht so gravierend, wie sie niedergemacht werden. Mäßigung und sachliche Aufklärung hilft in meinen Augen mehr als große Buchstaben und das ständige unbegründete Wiederholen.

(Warum soll ich nicht SELECT * schreiben)

Einige Argumente sind uralt und nicht mehr wirklich zutreffend.

Es stimmt immer noch, dass das Abfragen nicht benötigter Spalten überflüssig ist. Besonders bei großen Spaltentypen wie BLOB sollte man nicht ohne Grund selektieren. Ansonsten stammt das Argument aus Zeiten, in denen die Performance der Rechentechnik um Größenordnungen geringer als heute und jedes Einsparen deutlicher spürbar war. Bei überschaubarer Datenmenge fällt der zusätzliche Aufwand nicht so sehr ins Gewicht. Allerdings kommt jede eingesparte Rechenleistung dem Verbrauch zu Gute, so dass man dieses Argument nun wohl eher aus Umweltgründen bringen könnte ...

Das nächste Argument ist, dass "die Reihenfolge der Spalten bei der Ausgabe sonst undefiniert ist". Ja, aber wen interessiert das, wenn man sowieso über den Namen der Spalten auf selbige zugreift (*_fetch_assoc())?

Dass "die Spalten sonst möglicherweise keinen vernünftigen oder eindeutigen Namen haben" ist einerseits (vernünftiger Name) nur dann interessant, wenn man den Namen als Objekteigenschaftsnamen benötigt, andererseits (Eindeutigkeit) nur dann relevant, wenn man mehrere Tabellen in der Abfrage hat und sich dabei mehrere gleichnamige Spalten ergeben. Funktionen und berechnete Spalten lassen sich ja schließlich nicht mittels * notieren, so dass man bei deren Verwenden ohne Weiteres die Möglichkeit hat, einen Aliasnamen anzufügen.

Dann zitiert der Beitrag zum Zwecke der Begründung des allgemeinen Missbilligens das MySQL-Handbuch, das aber in dem Zitat nur von einem speziellen Fall spricht, nämlich dem Abfragen der Ergebnisse anhand der Position der Spalten, aber das macht nach meinen Beobachtungen (der hiesigen Datenbankfragen) so gut wie keiner. Die Seite, auf der es steht handelt vom Umsortieren von Spalten in einer Tabelle und der Satz ist mittlerweile deutlich harmloser geworden: "... you should never rely on using SELECT * and retrieving the columns based on their position." also "never rely" (nicht drauf verlassen) statt "never use" (nicht verwenden).

Beim Insert die Spalten anzugeben ist hingegen unbestritten sinnvoll, jedenfalls bei der Variante

INSERT INTO tabelle (spaltennamen) VALUES (werte)

denn hier greift man, lässt man die Spaltennamen weg, über die Position zu, was beim Spaltenlayoutändern Probleme nach sich ziehen kann.

Vorsintflutliche MySQL-Versionen (welche nutzt Du?) leiden leider unter akuter Microsoftitis Browseriensis ... sie sind bei Fehler viel zu nachgiebig, raten herum [...]
nicht nur vorsintflutliche - MySQL betrachtet die GROUP-BY-Funktionalität als ein besonderes Komfortfeature: GROUP BY hidden fields

Das ist zugegeben ein problematisches Feature, aber ein dokumentiertes. Dass Dokumentation ungern gelesen wird und mit MySQL als erstem DBMS "Aufgewachsene" die Problematik erst bei unerwarteten Ergebnissen bemerken, kreide ich nicht MySQL an. Auch bei mir musste seinerzeit erst ein Oracle (nebst Admin) kommen, um mich zum Nachdenken darüber anzuregen.

Um an die restlichen Daten von per Gruppierung ermittelten Datensätzen zu gelangen muss man das Gruppierungsergebnis wieder mit der gleichen Tabelle verknüpfen. Diesen Aufwand kann man sich und dem DBMS bei Eindeutigkeit sparen. Das Ergebnis wird dadurch nicht besser. Wenn nach der Gruppierung das Ergebnis mehrdeutig ist, ändert auch das Nichtzulassen der Abfrage wenig an dem Zustand. Einfach weitere Spalten beim Gruppieren anzugeben ist auch nicht die Antwort, beeinflusst das doch die Aggregatfunktionsergebnisse. Gelöst werden kann dieser Fall sicher nur auf anderem Wege und einzelfallabhängig.

Vielleicht wäre es besser gewesen, das Feature ONLY_FULL_GROUP_BY entgegengesetzt implementiert zu haben, so dass das Selektieren nur auf ausdrücklichen Wunsch möglich wird.

echo "$verabschiedung $name";

[Rouven]

Hello,

zunächst mal kriegst du ein "fachlich hilfreich" von mir, soviel vorweg! In deinem Posting steckt mit Sicherheit eine Menge Wahrheit drin.

Ich bin in den vergangenen zwei Jahren nur sehr nachrangig mit Datenbanken beschäftigt gewesen, aber arbeitsbedingt befasse ich mich gerade mit äußerst unschönen Daten- und Tabellenkonstellationen und kann aus dieser Perspektive nur ein paar Erfahrungen wiedergeben (die übrigens auch die von dir genannten Kommentare in SQL-Statements mit betreffen). Ich werde auch vorweg sagen, dass gerade Hobby-Entwickler mit Problemen dieser Dimension selten bis nie konfrontiert sein werden.

Beispiel zu den Kommentaren:
ein aktuelles Projekt läuft bei einem Kunden, dessen datenbankgestützte IT-Systeme mehrere Jahrzehnte alt sind. Alleine hierin fundieren politische Strukturen, die zu Entscheidungen führen, die auf den ersten Blick wenig sinnvoll erscheinen, so z.B. ablehnende Haltungen gegenüber Stored Procedures für unsere Zwecke. Dies zwingt uns eine Vielzahl von SQL-Statements, möglichst wartbar, außerhalb der Datenbank zu lagern. Die Statements haben eine derartige Komplexität erreicht, dass man praktisch jede Zeile kommentieren müsste, u.a. auch der Nachverfolgbarkeit von Defectfixes wegen. Es ist für uns deshalb durchaus ein realistischer Ansatz kommentierte Statements aus Resource-Dateien einzulesen und abzuschicken, wobei ich zugeben muss, dass die Kommentare selten direkter Bestandteil des SQL-Codes sind.

SELECT * hingegen lehne ich in einer Produktionsumgebung vehement ab. Unser derzeit entwickeltes System (bzw. diese Version) wird, wenn es gut läuft, lediglich 3-4, wenn es schlecht läuft deutlich länger laufen. Das Produkt, auf dem es aufsetzt, wird zwischenzeitlich auf eine neue Version migriert, deren Datenstrukturen sich teilweise deutlich von den aktuellen unterscheiden, insbesondere was Spalten, Defaultwerte etc. angeht. Wenn wir uns nun darauf verlassen, JOINs und anschließende Gruppierungen auf einem SELECT * aufzubauen, können wir mit 100% Wahrscheinlichkeit davon ausgehen, dass wir Nachbesserungen vornehmen müssen. Können wir hingegen die selektierten Spalten benennen, so ist die Wahrscheinlichkeit deutlich geringer. Was noch hinzukommt: das zugrundeliegende Datenmodell ist normalisiert, relevante Daten zu ermitteln, noch dazu in Archivbeständen, erfordert in den meisten Fällen eine ganze Reihe von JOINs. Ich mag gar nicht darüber nachdenken, wie man in derartigen Abfragen ohne angemessene Selects den Überblick über die Ergebnisspalten behalten möchte.

Und bezüglich des GROUP BY: ja, natürlich kann man den Gruppierungsvorgang erleichtern. Aber hiergegen habe ich zwei Einwände:

1. Der SQL-Standard sieht IMHO die MySQL-Variante NICHT vor. Wieso pochen wir bei HTML so darauf den Standards des W3C zu folgen, nur damit verlässliche Verarbeitung möglich wird, und sind bei SQL so nachlässig? Ein Standard ist ein Standard, warum darf man hier plötzlich die Standardsyntax benutzen, aber sich abweichend verhalten?
2. Ein Grund, warum Reflection/Eval/wie auch immer man es nennen mag verteufelt wird ist doch, dass man die Ausführung des Codes nicht vorhersagen kann. Eine syntaktische Validierung, die Analyse von Abhängigkeiten, der Programmfluss ist nicht durch Betrachtung des Quelltextes erkennbar. Genau hierauf läuft es doch bei der nicht-strikten GROUP BY Variante auch hinaus. Das Datenbanksystem akzeptiert einen Befehl, von dem es sagen kann "sieht vermutlich gut aus, ich kann dir aber nicht versprechen, dass die Auswertung dein Ergebnis ergibt - das hängt von der Datenkonstellation ab". Bei einem einfachen JOIN mag der Programmierer überblicken, ob die Auswahl der nicht-gruppierten Spalten eindeutig ist. Was ist, wenn der JOIN komplexer wird? Das DBMS wird keine Warnung rausgeben und sagen "oops, ich glaub da könnte was daneben gehen". Ich ändere ein Statement, ändere ein paar Daten und die Semantik meiner Abfrage ändert sich. Ich persönlich, und ja, ganz offensichtlich darf man hier geteilter Meinung sein, finde das gefährlich.

Wobei ich nicht leugnen werde, dass mir die eingangs erwähnten komplexen Statements im Projekt um einiges leichter von der Hand gingen, wenn ich etwas mutwilliger gruppieren dürfte :-)

Geruhsame Nacht, mich erwarten morgen weitere Multi-Bildschirmseiten-Queries!

MfG
Rouven

[dedlfix]

echo $begrüßung;

In deinem Posting steckt mit Sicherheit eine Menge Wahrheit drin.

Danke, das hoffe ich doch. Genauso wie ich hoffe, sachlich widerlegt zu bekommen, wenn dem nicht so ist.

Alleine hierin fundieren politische Strukturen, die zu Entscheidungen führen, die auf den ersten Blick wenig sinnvoll erscheinen, so z.B. ablehnende Haltungen gegenüber Stored Procedures für unsere Zwecke.

Achja</maulwurf>, Politik und (In)Kompetenzgerangel tragen nicht gerade zu idealen Bedingungen bei. Wenn die eine Rolle spielen muss man nachsichtig sein und versuchen, das Bestmögliche rauszuholen (oder aber dagegen ankämpfen, wenn es einem der Aufwand und die Aufregung wert ist).

SELECT * hingegen lehne ich in einer Produktionsumgebung vehement ab.

Das ist mir im Prinzip zu dogmentiert.

[...] Wenn wir uns nun darauf verlassen, JOINs und anschließende Gruppierungen auf einem SELECT * aufzubauen, können wir mit 100% Wahrscheinlichkeit davon ausgehen, dass wir Nachbesserungen vornehmen müssen. Können wir hingegen die selektierten Spalten benennen, so ist die Wahrscheinlichkeit deutlich geringer.

Das hingegen ist ein nachvollziehbares Argument, SELECT * nicht einzusetzen. Aufgrund dessen (plus weiterer (sinnbehafteter) Argumente) kann man meinetwegen gern als (projektspezifischen) Standard festlegen, Spaltennamen explizit anzuführen. Wenn es allerdings im Laufe der Zeit nur noch Dogma geworden ist, dann wird es immer weniger nachvollziehbar und findet in mir keinen Fürsprecher.

1. Der SQL-Standard sieht IMHO die MySQL-Variante NICHT vor. Wieso pochen wir bei HTML so darauf den Standards des W3C zu folgen, nur damit verlässliche Verarbeitung möglich wird, und sind bei SQL so nachlässig? Ein Standard ist ein Standard, warum darf man hier plötzlich die Standardsyntax benutzen, aber sich abweichend verhalten?

Bei HTML muss eine Quelle von verschiedenen Systemen interpretiert werden. SQL-Statements schneidert man meist dem verwendeten DBMS direkt auf den Leib. Unter anderem deshalb, um die spezifischen Features des DBMS zu nutzen. Der Sinn eines Standards ist eine Austauschbarkeit, doch die ist in den meisten Fällen einfach nicht gefragt. Die Austauschbarkeit bedingt einen teilweise erheblichen Verzicht auf Features, was ich als einen schwerwiegenderen Nachteil ansehe. Wenn beispielsweise als Vorteil der Umstieg auf ein kostengünstigeres System in Betracht kommt, dann haben wir die oben erwähnte Politik im Spiel und technische Argumente schlechte Karten.

Bei einem einfachen JOIN mag der Programmierer überblicken, ob die Auswahl der nicht-gruppierten Spalten eindeutig ist. Was ist, wenn der JOIN komplexer wird? Das DBMS wird keine Warnung rausgeben und sagen "oops, ich glaub da könnte was daneben gehen". Ich ändere ein Statement, ändere ein paar Daten und die Semantik meiner Abfrage ändert sich. Ich persönlich, und ja, ganz offensichtlich darf man hier geteilter Meinung sein, finde das gefährlich.

Potentiell gefährlich ist alles, was man ohne ausreichendes Wissen anwendet. Man kann auch mit register_globals=on unter PHP sichere Scripte programmieren. Nicht das Feature ist das Böse sondern der unachtsame Umgang damit. Wenn es ein "gefährliches" Feature nicht gibt, finden Unachtsame garantiert andere Wege, sich selbst ins Knie zu schießen. Wissen um die Wirkungsweise und verantwortungsvoller Umgang (wobei auch ein Nichtbenutzen eine Option sein kann) ist für mich das Ideal.

echo "$verabschiedung $name";

[Ilja]

yo,

will mich mal kurz einklincken in die diskussion...

ich sehe es wie dedlfix, "werkzeuge" wie das * sollte man nicht grundsätzlich verteufeln. es hat die funktion immer alle spalten anzuzeigen. und genauo dort, wo dieser effekt erwünscht ist, genau dort macht es auch sinn, das zu tun, aber auch nur dort. das kann unter anderem auch im produktiveinsatz sein, wenn eben genau dieser effekt benötigt wird.

auf der anderen seite sehe ich das wie Rouven, es nicht dort einzusetzen, wo ich es nicht unbedinkt brauche. das argument, dass sich die zeiten geändert haben und speicherplatz/performance heute nicht mehr so ein problem ist wie früher, solange keinen spalten ala BLOB eingesetzt werden, das hinkt ein wenig. ich kann ja zum beispiel gar nicht sicher stellen, dass in der zukunft dort keine BLOB spalte sein wird.

ergo, spalten immer benennen, wo ich immer nur bestimmte spalten brauche, das * immer dort einsetzen, wo ich immer alle spalte benötige (testzwecke mal ausgenommen oder ad hoc abfragen).

was die standartisierung des sql betrifft, so gibt es natürlich dbms spezifische dialekte, die vom standard abweichen. aber das ist noch lange kein grund, immer mehr davon abzuweichen, ist sollte es nach möglichkeit vermeiden. realtionale dbms konnten sich eben unter anderem genau deswegen durchsestzen, weil sie enien standard in ihrer kommunikatinsprache haben.

was das verwenden von GROUP BY unter mysql betrifft, so ist es ein abwägen der vor und nachteile. und für mich überwiegen die nachteile dabei. ich würde mysql dazu raten, sich wieder an den standard zu halten.

Ilja

[Rouven]

Hello,

was die standartisierung des sql betrifft, so gibt es natürlich dbms spezifische dialekte, die vom standard abweichen.

genau zu dem Punkt kam mir heute morgen auch nochmal ein Gedanke, insbesondere nachdem dedlfix - richtigerweise - angemerkt hat, dass man sich mit der Dokumentation des DBMS auseinandersetzen müsste/sollte.
Das ist ja soweit richtig, ebenso wie es richtig ist, dass viele Anwendungen niemals portiert werden auf andere DBMS. Aber ich würde davon ausgehen, dass ich in die Dokumentation reinschaue um herauszufinden was ich BESSER machen kann, als der Standard. Zusätzliche Features, zusätzliche Befehle. Dass ich dort hereinschauen muss um zu sehen, wo sich das System NICHT so verhält wie der Standard es vorgibt finde ich irritierend. Ich möchte eigentlich nicht als erstes nach der Installation eines DBMS nachschauen, ob SELECT mir eine Selektion auf dem FROM-Teil macht, oder zusätzliche Spalten irgendwo anders in der Datenbank suchen geht, weil ein Entwickler das als Feature betrachtet.
Und da komme ich nochmal zurück auf Syntax und Semantik: Wenn ich einen Befehl verwende, der in einem anderen DBMS nicht unterstützt wird, dann wird das DBMS mir das durch deutlichen Protest zeigen. Wenn ich aber einen Befehl habe, der Teil des Standards ist, und dessen Semantik eine andere ist, dann halte ich das wiederum für gefährlich.
Ich werde aber auch hier wieder etwas einlenken: MySQL ist schließlich nachlässiger als andere Systeme, ich dürfte den Befehl also nicht "aus Versehen" irgendwo ans Laufen kriegen.

MfG
Rouven

[Ilja]

yo,

Aber ich würde davon ausgehen, dass ich in die Dokumentation reinschaue um herauszufinden was ich BESSER machen kann, als der Standard. Zusätzliche Features, zusätzliche Befehle. Dass ich dort hereinschauen muss um zu sehen, wo sich das System NICHT so verhält wie der Standard es vorgibt finde ich irritierend.

dem stimme ich zu, gerade eine stärke von rdbms ist eben dieser standard. war grausam als Oracle noch keine explizite INNER JOIN schreibweise beherschte, das macht keinen sinn, dokumentation hin oder her.

Ilja

[mrtee]

und wieso hilft dir DISTINCT nicht weiter ?

<zitat>
Durch DISTINCT werden ALLE doppelten Einträge entfernt, was mir so nicht  weiterhilft
</zitat>