Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
kein Monat in PostgreSQL
11 views
Skip to first unread message
Marc Santhoff
Nov 16, 2012, 12:35:51 PM11/16/12
to
Moin,
stimmt es wirklich, postgres hat keine "month()"-Funktion, sondern man
muß "date_part('month', ...)" benutzen?
Marc
stimmt es wirklich, postgres hat keine "month()"-Funktion, sondern man
muß "date_part('month', ...)" benutzen?
Marc
Siegfried Schmidt
Nov 16, 2012, 1:27:08 PM11/16/12
to
Marc Santhoff schrieb:
> stimmt es wirklich, postgres hat keine "month()"-Funktion, sondern man
> muß "date_part('month', ...)" benutzen?
Es stimmt, aber du muss deswegen noch lange nicht date_part benutzen.
create function month(timestamp) returns integer as $$
select date_part('month',$1)::integer;
$$ language sql;
Siegfried
> stimmt es wirklich, postgres hat keine "month()"-Funktion, sondern man
> muß "date_part('month', ...)" benutzen?
create function month(timestamp) returns integer as $$
select date_part('month',$1)::integer;
$$ language sql;
Siegfried
Marc Santhoff
Nov 16, 2012, 1:35:50 PM11/16/12
to
Am Fri, 16 Nov 2012 18:27:08 +0000 (UTC)
schrieb Siegfried Schmidt <usen...@shivasoft.de>:
> Marc Santhoff schrieb:
>
> > stimmt es wirklich, postgres hat keine "month()"-Funktion, sondern
> > man muß "date_part('month', ...)" benutzen?
>
> Es stimmt, aber du muss deswegen noch lange nicht date_part benutzen.
OK, danke für die Bestätigung.
> create function month(timestamp) returns integer as $$
> select date_part('month',$1)::integer;
> $$ language sql;
Schon klar. Aber irgendwie auch "absichtliche Inkompatibilität". Wenn
ich richtig erinnere haben mindestens drei namhafte DBen, mit denen
ich zu tun hatte, die gesuchte Funktion ... jaja, date_part() ist
universeller, usw. Deswegen muß jetzt jeder für universlles SQL die
Funktion erstmal definieren.
Bestimmt kannst Du garnichts dafür. :)
Grummel,
Marc
schrieb Siegfried Schmidt <usen...@shivasoft.de>:
> Marc Santhoff schrieb:
>
> > stimmt es wirklich, postgres hat keine "month()"-Funktion, sondern
> > man muß "date_part('month', ...)" benutzen?
>
> Es stimmt, aber du muss deswegen noch lange nicht date_part benutzen.
> create function month(timestamp) returns integer as $$
> select date_part('month',$1)::integer;
> $$ language sql;
ich richtig erinnere haben mindestens drei namhafte DBen, mit denen
ich zu tun hatte, die gesuchte Funktion ... jaja, date_part() ist
universeller, usw. Deswegen muß jetzt jeder für universlles SQL die
Funktion erstmal definieren.
Bestimmt kannst Du garnichts dafür. :)
Grummel,
Marc
Andreas Scherbaum
Nov 17, 2012, 5:17:56 AM11/17/12
to
Marc Santhoff <m.san...@t-online.de> wrote:
>
> Schon klar. Aber irgendwie auch "absichtliche Inkompatibilität".
Warum ist alles gleich inkompatibel, und dann auch noch
>
> Schon klar. Aber irgendwie auch "absichtliche Inkompatibilität".
mit Absicht? ;-)
Bei der Verwendung einer Datenbank geht man nicht erst
mal davon aus das jemand von einer anderen Datenbanksoftware
auf die neue Software migriert. Wenn doch - die Abhilfe
war nun wirklich schnell erstellt, oder?
--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)
Marc Santhoff
Nov 17, 2012, 8:43:27 AM11/17/12
to
Am Sat, 17 Nov 2012 11:17:56 +0100
schrieb Andreas Scherbaum <ads-...@wars-nicht.de>:
> Marc Santhoff <m.san...@t-online.de> wrote:
> >
> > Schon klar. Aber irgendwie auch "absichtliche Inkompatibilität".
>
> Warum ist alles gleich inkompatibel, und dann auch noch
> mit Absicht? ;-)
Das ist die Frage, ja. ;)
> Bei der Verwendung einer Datenbank geht man nicht erst
> mal davon aus das jemand von einer anderen Datenbanksoftware
> auf die neue Software migriert. Wenn doch - die Abhilfe
> war nun wirklich schnell erstellt, oder?
Ich verstehe das alles sehr gut, aber aus Sicht von jemand, der nicht
nur mit einer DB arbeitet, ist das erstmal ein überflüssiges Hindernis.
Natürlich kann man argumentieren, der Fall würde nicht so häufig
vorkommen, aber Programmierer die nur am Rand mit SQL zu tun haben gibt
es IMHO genug.
Aus meiner derzeitigen Sicht ist das eine Ausnahme, deren Grund ich
ermitteln, eine Lösung finden und den ganzen Schmus dokumentieren muß -
hätte es die Funktion MONTH() als Alias auf date_part() gleich gegeben,
bräuchte ich das nicht.
Nix für ungut,
Marc
--
Hier läuft Ehnix, voll kompatibel zu Garnix
schrieb Andreas Scherbaum <ads-...@wars-nicht.de>:
> Marc Santhoff <m.san...@t-online.de> wrote:
> >
> > Schon klar. Aber irgendwie auch "absichtliche Inkompatibilität".
>
> Warum ist alles gleich inkompatibel, und dann auch noch
> mit Absicht? ;-)
> Bei der Verwendung einer Datenbank geht man nicht erst
> mal davon aus das jemand von einer anderen Datenbanksoftware
> auf die neue Software migriert. Wenn doch - die Abhilfe
> war nun wirklich schnell erstellt, oder?
nur mit einer DB arbeitet, ist das erstmal ein überflüssiges Hindernis.
Natürlich kann man argumentieren, der Fall würde nicht so häufig
vorkommen, aber Programmierer die nur am Rand mit SQL zu tun haben gibt
es IMHO genug.
Aus meiner derzeitigen Sicht ist das eine Ausnahme, deren Grund ich
ermitteln, eine Lösung finden und den ganzen Schmus dokumentieren muß -
hätte es die Funktion MONTH() als Alias auf date_part() gleich gegeben,
bräuchte ich das nicht.
Nix für ungut,
Marc
--
Hier läuft Ehnix, voll kompatibel zu Garnix
Andreas Scherbaum
Nov 17, 2012, 9:45:36 AM11/17/12
to
Marc Santhoff <m.san...@t-online.de> wrote:
>
> Natürlich kann man argumentieren, der Fall würde nicht so häufig
> vorkommen, aber Programmierer die nur am Rand mit SQL zu tun haben gibt
> es IMHO genug.
Ich gebe ja zu ich bin da gegenüber PostgreSQL voreingenommen.
>
> Natürlich kann man argumentieren, der Fall würde nicht so häufig
> vorkommen, aber Programmierer die nur am Rand mit SQL zu tun haben gibt
> es IMHO genug.
Allerdings kann ich dein Argument nicht ganz nachvollziehen:
Die allgemeine Funktion bietet dir alle Freiheiten und
außerdem kannst du dir sehr einfach eine weitere passende Funktion
drumherum schrauben. Natürlich könnte man für jeden Sonderfall
auch gleich die passenden Funktionen mit liefern ... artet dann
allerdings irgendwann aus weil jeder mit Extrawünschen ankommt:
(Jahr bitte einmal zweistellig, einmal vierstellig, einmal seit 1900,
einmal seit 1970 (Unix), einmal seit 1899/1904 (Windows) - und da
sind noch gar nicht die ganzen Religionen eingerechnet. Monat und
Tag bitte wahlweise auch mit und ohne führender Null.
Gegenfrage: wie löst du die ganzen Sonderwünsche auf wenn
du nur year() month() und day() zur Verfügung hast?
Marc Santhoff
Nov 17, 2012, 10:29:40 AM11/17/12
to
Am Sat, 17 Nov 2012 15:45:36 +0100
schrieb Andreas Scherbaum <ads-...@wars-nicht.de>:
> Marc Santhoff <m.san...@t-online.de> wrote:
> >
> > Natürlich kann man argumentieren, der Fall würde nicht so häufig
> > vorkommen, aber Programmierer die nur am Rand mit SQL zu tun haben
> > gibt es IMHO genug.
>
> Ich gebe ja zu ich bin da gegenüber PostgreSQL voreingenommen.
> Allerdings kann ich dein Argument nicht ganz nachvollziehen:
>
> Die allgemeine Funktion bietet dir alle Freiheiten und
> außerdem kannst du dir sehr einfach eine weitere passende Funktion
> drumherum schrauben. Natürlich könnte man für jeden Sonderfall
> auch gleich die passenden Funktionen mit liefern ... artet dann
> allerdings irgendwann aus weil jeder mit Extrawünschen ankommt:
> (Jahr bitte einmal zweistellig, einmal vierstellig, einmal seit 1900,
> einmal seit 1970 (Unix), einmal seit 1899/1904 (Windows) - und da
> sind noch gar nicht die ganzen Religionen eingerechnet. Monat und
> Tag bitte wahlweise auch mit und ohne führender Null.
Ich betonte ja schon, ich verstehe durchaus den Ansatz, eine Funktion
für alles zu benutzen und die ganzen Variationen mit Parameter à la
printf() zu erledigen.
Mich ärgern nur solche kleinen Unterschiede, die ich aus meiner Sicht
für unnötig halte, weil sie Zeit fressen. Erinnert mich irgendwie an
die Diskussionen über Open Source, $HERSTELLER ist pöhse, weil er sein
Produkt inkompatibel macht, und mit OSS wird alles besser. ;)
> Gegenfrage: wie löst du die ganzen Sonderwünsche auf wenn
> du nur year() month() und day() zur Verfügung hast?
Ich habe bisher keine Sonderwünsche zu lösen. Nur relativ simples SQL,
das aber auf MySQL (aber zunehmend seltener), Firebird, HSQL und
PostgreSQL möglichst ohne Klimmzüge laufen soll. Und ich muß
netterweise auch keine unterschiedlichen Lokalitäten unterstützen. Wenn
doch, würde ich mir eine Fktn. wie date_part() wünschen. :)
Ich höre schon die nächsten Argumente, das ist ja auch nur ein
beschränkter Ausschnitt, der nächste will DB $X, dann einer $Y, das
kann man nicht alles berücksichtigen ...
Was sagen eigentlich die verschiedenen SQL-Standards dazu, sind diese
Funktionen dort irgendwie erwähnt?
Marc
--
This computer is not running MICROS~1.
schrieb Andreas Scherbaum <ads-...@wars-nicht.de>:
> Marc Santhoff <m.san...@t-online.de> wrote:
> >
> > Natürlich kann man argumentieren, der Fall würde nicht so häufig
> > vorkommen, aber Programmierer die nur am Rand mit SQL zu tun haben
> > gibt es IMHO genug.
>
> Ich gebe ja zu ich bin da gegenüber PostgreSQL voreingenommen.
> Allerdings kann ich dein Argument nicht ganz nachvollziehen:
>
> Die allgemeine Funktion bietet dir alle Freiheiten und
> außerdem kannst du dir sehr einfach eine weitere passende Funktion
> drumherum schrauben. Natürlich könnte man für jeden Sonderfall
> auch gleich die passenden Funktionen mit liefern ... artet dann
> allerdings irgendwann aus weil jeder mit Extrawünschen ankommt:
> (Jahr bitte einmal zweistellig, einmal vierstellig, einmal seit 1900,
> einmal seit 1970 (Unix), einmal seit 1899/1904 (Windows) - und da
> sind noch gar nicht die ganzen Religionen eingerechnet. Monat und
> Tag bitte wahlweise auch mit und ohne führender Null.
für alles zu benutzen und die ganzen Variationen mit Parameter à la
printf() zu erledigen.
Mich ärgern nur solche kleinen Unterschiede, die ich aus meiner Sicht
für unnötig halte, weil sie Zeit fressen. Erinnert mich irgendwie an
die Diskussionen über Open Source, $HERSTELLER ist pöhse, weil er sein
Produkt inkompatibel macht, und mit OSS wird alles besser. ;)
> Gegenfrage: wie löst du die ganzen Sonderwünsche auf wenn
> du nur year() month() und day() zur Verfügung hast?
das aber auf MySQL (aber zunehmend seltener), Firebird, HSQL und
PostgreSQL möglichst ohne Klimmzüge laufen soll. Und ich muß
netterweise auch keine unterschiedlichen Lokalitäten unterstützen. Wenn
doch, würde ich mir eine Fktn. wie date_part() wünschen. :)
Ich höre schon die nächsten Argumente, das ist ja auch nur ein
beschränkter Ausschnitt, der nächste will DB $X, dann einer $Y, das
kann man nicht alles berücksichtigen ...
Was sagen eigentlich die verschiedenen SQL-Standards dazu, sind diese
Funktionen dort irgendwie erwähnt?
Marc
--
This computer is not running MICROS~1.
Message has been deleted
Andreas Scherbaum
Nov 17, 2012, 4:31:55 PM11/17/12
to
Oliver Sch@d <spam.entfernen.und.bring...@oschad.de> wrote:
> konrete Implementierung als Basis zu nehmen - sonst wirst du immer in
> solche Fallen stolpern.
Das allwissende Orakel im IRC meint das EXTRACT() im Standard
steht. Das gibt es dann auch in MySQL.
> Marc Santhoff wrote:
>
>> Am Fri, 16 Nov 2012 18:27:08 +0000 (UTC)
>
>> Am Fri, 16 Nov 2012 18:27:08 +0000 (UTC)
>>> create function month(timestamp) returns integer as $$
>>> select date_part('month',$1)::integer;
>>> $$ language sql;
>>
>> Schon klar. Aber irgendwie auch "absichtliche Inkompatibilität".
>
> Ich würde dir empfehlen vom SQL-Standard auszugehen und nicht eine
>>> select date_part('month',$1)::integer;
>>> $$ language sql;
>>
>> Schon klar. Aber irgendwie auch "absichtliche Inkompatibilität".
>
> konrete Implementierung als Basis zu nehmen - sonst wirst du immer in
> solche Fallen stolpern.
Das allwissende Orakel im IRC meint das EXTRACT() im Standard
steht. Das gibt es dann auch in MySQL.
Dieter Strassner
Nov 18, 2012, 8:43:30 AM11/18/12
to
Hallo Andreas,
> Die allgemeine Funktion bietet dir alle Freiheiten und
> außerdem kannst du dir sehr einfach eine weitere passende Funktion
> drumherum schrauben. Natürlich könnte man für jeden Sonderfall
> auch gleich die passenden Funktionen mit liefern ... artet dann
> allerdings irgendwann aus weil jeder mit Extrawünschen ankommt:
> (Jahr bitte einmal zweistellig, einmal vierstellig, einmal seit 1900,
> einmal seit 1970 (Unix), einmal seit 1899/1904 (Windows) - und da
> sind noch gar nicht die ganzen Religionen eingerechnet. Monat und
> Tag bitte wahlweise auch mit und ohne führender Null.
>
> Gegenfrage: wie löst du die ganzen Sonderwünsche auf wenn
> du nur year() month() und day() zur Verfügung hast?
Generell:
Die Darstellungsform ist "üblicherweise" Sache der clientseitigen Software.
Eine Datenbank ist zum speichern und wiederfinden der Daten gebaut. Deine
Software wandelt das Datum dann so um, wie benötigt wird.
Bei einigen SQL-Abfragen kann es natürlich äußerst hilfreich sein,
Funktionen wie year() month() und day() zu Verfügung zu haben. Wenn es die
ebennicht gibt, heißt es Kompromisse machen... (...der andereDB)
--
Viele Grüße - Dieter
EDV-Kommunikation Strassner e.K.
68623 Lampertheim
Internet: www.strassner.biz
> Die allgemeine Funktion bietet dir alle Freiheiten und
> außerdem kannst du dir sehr einfach eine weitere passende Funktion
> drumherum schrauben. Natürlich könnte man für jeden Sonderfall
> auch gleich die passenden Funktionen mit liefern ... artet dann
> allerdings irgendwann aus weil jeder mit Extrawünschen ankommt:
> (Jahr bitte einmal zweistellig, einmal vierstellig, einmal seit 1900,
> einmal seit 1970 (Unix), einmal seit 1899/1904 (Windows) - und da
> sind noch gar nicht die ganzen Religionen eingerechnet. Monat und
> Tag bitte wahlweise auch mit und ohne führender Null.
>
> Gegenfrage: wie löst du die ganzen Sonderwünsche auf wenn
> du nur year() month() und day() zur Verfügung hast?
Die Darstellungsform ist "üblicherweise" Sache der clientseitigen Software.
Eine Datenbank ist zum speichern und wiederfinden der Daten gebaut. Deine
Software wandelt das Datum dann so um, wie benötigt wird.
Bei einigen SQL-Abfragen kann es natürlich äußerst hilfreich sein,
Funktionen wie year() month() und day() zu Verfügung zu haben. Wenn es die
ebennicht gibt, heißt es Kompromisse machen... (...der andereDB)
--
Viele Grüße - Dieter
EDV-Kommunikation Strassner e.K.
68623 Lampertheim
Internet: www.strassner.biz
Dieter Strassner
Nov 18, 2012, 8:44:49 AM11/18/12
to
Sorry, sollten lauten
... (...oder andere DB)
... (...oder andere DB)
Marc Santhoff
Nov 18, 2012, 9:17:28 AM11/18/12
to
Am Sat, 17 Nov 2012 19:38:20 +0100
schrieb "Oliver Sch@d"
<spam.entfernen.und.bring...@oschad.de>:
> Marc Santhoff wrote:
>
> > Am Fri, 16 Nov 2012 18:27:08 +0000 (UTC)
wieder die Standards zu Gemüte führen und auch zum Nachschlagen
bereitlegen.
Tatsächlich ist man damit aber lange nicht am Ziel, denn man muß für
jede Version der benutzen DBen eine Liste wenigstens der nicht
implementierten Bestandteile führen oder im Zugriff haben ...
Marc
--
Ihr Suchbegriff >freebsd< könnte fehlerhaft oder unbekannt sein:
Ob Freibad besser ist? (Suchmaschine)
schrieb "Oliver Sch@d"
<spam.entfernen.und.bring...@oschad.de>:
> Marc Santhoff wrote:
>
> > Am Fri, 16 Nov 2012 18:27:08 +0000 (UTC)
> >> create function month(timestamp) returns integer as $$
> >> select date_part('month',$1)::integer;
> >> $$ language sql;
> >
> > Schon klar. Aber irgendwie auch "absichtliche Inkompatibilität".
>
> >> select date_part('month',$1)::integer;
> >> $$ language sql;
> >
> > Schon klar. Aber irgendwie auch "absichtliche Inkompatibilität".
>
> Ich würde dir empfehlen vom SQL-Standard auszugehen und nicht eine
> konrete Implementierung als Basis zu nehmen - sonst wirst du immer in
> solche Fallen stolpern.
Du hast selbstverständlich in erster Näherung recht, ich werde mir mal
> konrete Implementierung als Basis zu nehmen - sonst wirst du immer in
> solche Fallen stolpern.
wieder die Standards zu Gemüte führen und auch zum Nachschlagen
bereitlegen.
Tatsächlich ist man damit aber lange nicht am Ziel, denn man muß für
jede Version der benutzen DBen eine Liste wenigstens der nicht
implementierten Bestandteile führen oder im Zugriff haben ...
Marc
--
Ihr Suchbegriff >freebsd< könnte fehlerhaft oder unbekannt sein:
Ob Freibad besser ist? (Suchmaschine)
Andreas Scherbaum
Nov 18, 2012, 3:14:59 PM11/18/12
to
Marc Santhoff <m.san...@t-online.de> wrote:
>
> Tatsￜchlich ist man damit aber lange nicht am Ziel, denn man muￜ fￜr
Lass mich nach deinen Tests wissen welche Datenbank am Ende
die meisten "nicht implementiert" und "anders als im Standard
implementiert" und "nur teilweise implementiert" aufweist.
>
> Tatsￜchlich ist man damit aber lange nicht am Ziel, denn man muￜ fￜr
> jede Version der benutzen DBen eine Liste wenigstens der nicht
> implementierten Bestandteile fï¿œhren oder im Zugriff haben ...
Lass mich nach deinen Tests wissen welche Datenbank am Ende
die meisten "nicht implementiert" und "anders als im Standard
implementiert" und "nur teilweise implementiert" aufweist.
Message has been deleted
Lutz Donnerhacke
Nov 20, 2012, 9:00:25 AM11/20/12
to
* Oliver Sch@d wrote:
Oh, Du kennst die wirklich abartigen Systeme noch nicht.
> Andreas Scherbaum wrote:
>> Lass mich nach deinen Tests wissen welche Datenbank am Ende
>> die meisten "nicht implementiert" und "anders als im Standard
>> implementiert" und "nur teilweise implementiert" aufweist.
>
> Das ist leicht: MySQL.
>> Lass mich nach deinen Tests wissen welche Datenbank am Ende
>> die meisten "nicht implementiert" und "anders als im Standard
>> implementiert" und "nur teilweise implementiert" aufweist.
>
Oh, Du kennst die wirklich abartigen Systeme noch nicht.
Andreas Scherbaum
Nov 21, 2012, 6:23:12 AM11/21/12
to
Oliver Sch@d <spam.entfernen.und.bring...@oschad.de> wrote:
> Andreas Scherbaum wrote:
>
>> Marc Santhoff <m.san...@t-online.de> wrote:
>>>
>>> Tatsächlich ist man damit aber lange nicht am Ziel, denn man muß für
Ich wollte das nicht so eindeutig fragen ;-)
> Andreas Scherbaum wrote:
>
>> Marc Santhoff <m.san...@t-online.de> wrote:
>>>
>>> Tatsächlich ist man damit aber lange nicht am Ziel, denn man muß für
>>> jede Version der benutzen DBen eine Liste wenigstens der nicht
>>> implementierten Bestandteile führen oder im Zugriff haben ...
>>
>> Lass mich nach deinen Tests wissen welche Datenbank am Ende
>> die meisten "nicht implementiert" und "anders als im Standard
>> implementiert" und "nur teilweise implementiert" aufweist.
>
> Das ist leicht: MySQL.
>> Lass mich nach deinen Tests wissen welche Datenbank am Ende
>> die meisten "nicht implementiert" und "anders als im Standard
>> implementiert" und "nur teilweise implementiert" aufweist.
>
Ich wollte das nicht so eindeutig fragen ;-)
Marc Santhoff
Nov 21, 2012, 10:42:02 AM11/21/12
to
Am Wed, 21 Nov 2012 12:23:12 +0100
schrieb Andreas Scherbaum <ads-...@wars-nicht.de>:
> Oliver Sch@d
> <spam.entfernen.und.bring...@oschad.de> wrote:
> > Andreas Scherbaum wrote:
> >
> >> Marc Santhoff <m.san...@t-online.de> wrote:
> >>>
> >>> Tatsächlich ist man damit aber lange nicht am Ziel, denn man muß
> >>> für jede Version der benutzen DBen eine Liste wenigstens der nicht
> >>> implementierten Bestandteile führen oder im Zugriff haben ...
> >>
> >> Lass mich nach deinen Tests wissen welche Datenbank am Ende
> >> die meisten "nicht implementiert" und "anders als im Standard
> >> implementiert" und "nur teilweise implementiert" aufweist.
> >
> > Das ist leicht: MySQL.
>
> Ich wollte das nicht so eindeutig fragen ;-)
Ich berichte gern, aber das kann dauern. Ich habe nicht die
Möglichkeit, gezielt und zeitlich konzentriert nach Unterschieden zu
suchen, also liste ich nur auf, was mir begegnet.
Und speziell zu MySQL: da es für seine Seltsamkeit bekannt ist, wird es
nur noch in Ausnahmefällen unterstützt, nicht mehr als Standardfall. Ob
da was nachrückt, weiß ich noch nicht.
Neulich grade erst wieder eine Abfrage gefunden, à la:
select a, b from t where ... group by a;
Funktioniert, in MySQL 4.x.
Marc
schrieb Andreas Scherbaum <ads-...@wars-nicht.de>:
> Oliver Sch@d
> <spam.entfernen.und.bring...@oschad.de> wrote:
> > Andreas Scherbaum wrote:
> >
> >> Marc Santhoff <m.san...@t-online.de> wrote:
> >>>
> >>> Tatsächlich ist man damit aber lange nicht am Ziel, denn man muß
> >>> für jede Version der benutzen DBen eine Liste wenigstens der nicht
> >>> implementierten Bestandteile führen oder im Zugriff haben ...
> >>
> >> Lass mich nach deinen Tests wissen welche Datenbank am Ende
> >> die meisten "nicht implementiert" und "anders als im Standard
> >> implementiert" und "nur teilweise implementiert" aufweist.
> >
> > Das ist leicht: MySQL.
>
> Ich wollte das nicht so eindeutig fragen ;-)
Möglichkeit, gezielt und zeitlich konzentriert nach Unterschieden zu
suchen, also liste ich nur auf, was mir begegnet.
Und speziell zu MySQL: da es für seine Seltsamkeit bekannt ist, wird es
nur noch in Ausnahmefällen unterstützt, nicht mehr als Standardfall. Ob
da was nachrückt, weiß ich noch nicht.
Neulich grade erst wieder eine Abfrage gefunden, à la:
select a, b from t where ... group by a;
Funktioniert, in MySQL 4.x.
Marc
Lutz Donnerhacke
Nov 21, 2012, 12:08:39 PM11/21/12
to
* Marc Santhoff wrote:
> Und speziell zu MySQL: da es f�r seine Seltsamkeit bekannt ist, wird es
> nur noch in Ausnahmef�llen unterst�tzt, nicht mehr als Standardfall.
Echt? Es gibt Hoffnung? Ist der MySQL Treiber im PHP entg�ltig kaputt?
> Und speziell zu MySQL: da es f�r seine Seltsamkeit bekannt ist, wird es
> nur noch in Ausnahmef�llen unterst�tzt, nicht mehr als Standardfall.
Echt? Es gibt Hoffnung? Ist der MySQL Treiber im PHP entg�ltig kaputt?
Marc Santhoff
Nov 21, 2012, 12:28:31 PM11/21/12
to
Am Wed, 21 Nov 2012 17:08:39 +0000 (UTC)
schrieb Lutz Donnerhacke <lu...@iks-jena.de>:
> * Marc Santhoff wrote:
> > Und speziell zu MySQL: da es für seine Seltsamkeit bekannt ist,
> > wird es nur noch in Ausnahmefällen unterstützt, nicht mehr als
> > Standardfall.
>
> Echt? Es gibt Hoffnung? Ist der MySQL Treiber im PHP entgültig kaputt?
Ich kann nur von mir selbst ausgehen, und in meiner langfristigen
Wahrnehmung hat sich MySQL von einer funktionsarmen und deswegen
sauschnellen Datenbank (Version 2 konnte IIRC keine sub-selects, hat
aber alle ehrwürdigen alten Damen wie z.B. Interbase bei den
Antwortzeiten statisch aussehen lassen) zu einem ausgewachsenen
DB-Server entwickelt, es aber irgendwie nie in die Liga der großen
geschafft. Vielleicht weil immer noch der Schwerpunkt auf Einfachheit
lag.
Und da nun die Irritationen rund um offene Quellen dazu gekommen sind
und auch noch Oracle Eigentümer ist ...
Und was ist PHP, eine Palästinensische Politfraktion?
Marc
--
Texanischer Ethnologe über die Neigung der Deutschen, die Sinnfrage zu
stellen: "Die schärfsten Denker fragen sogar, welchen Sinn, angenommen
es gäbe ihn, ein Sinn hätte." (Richard W. B. McCormack)
schrieb Lutz Donnerhacke <lu...@iks-jena.de>:
> * Marc Santhoff wrote:
> > Und speziell zu MySQL: da es für seine Seltsamkeit bekannt ist,
> > wird es nur noch in Ausnahmefällen unterstützt, nicht mehr als
> > Standardfall.
>
> Echt? Es gibt Hoffnung? Ist der MySQL Treiber im PHP entgültig kaputt?
Ich kann nur von mir selbst ausgehen, und in meiner langfristigen
Wahrnehmung hat sich MySQL von einer funktionsarmen und deswegen
sauschnellen Datenbank (Version 2 konnte IIRC keine sub-selects, hat
aber alle ehrwürdigen alten Damen wie z.B. Interbase bei den
Antwortzeiten statisch aussehen lassen) zu einem ausgewachsenen
DB-Server entwickelt, es aber irgendwie nie in die Liga der großen
geschafft. Vielleicht weil immer noch der Schwerpunkt auf Einfachheit
lag.
Und da nun die Irritationen rund um offene Quellen dazu gekommen sind
und auch noch Oracle Eigentümer ist ...
Und was ist PHP, eine Palästinensische Politfraktion?
Marc
--
Texanischer Ethnologe über die Neigung der Deutschen, die Sinnfrage zu
stellen: "Die schärfsten Denker fragen sogar, welchen Sinn, angenommen
es gäbe ihn, ein Sinn hätte." (Richard W. B. McCormack)
Bernd Nawothnig
Nov 21, 2012, 1:23:08 PM11/21/12
to
On 2012-11-21, Marc Santhoff wrote:
> Am Wed, 21 Nov 2012 17:08:39 +0000 (UTC)
> schrieb Lutz Donnerhacke <lu...@iks-jena.de>:
>
>> * Marc Santhoff wrote:
>> > Und speziell zu MySQL: da es für seine Seltsamkeit bekannt ist,
>> > wird es nur noch in Ausnahmefällen unterstützt, nicht mehr als
>> > Standardfall.
>>
>> Echt? Es gibt Hoffnung? Ist der MySQL Treiber im PHP entgültig kaputt?
>
> Ich kann nur von mir selbst ausgehen, und in meiner langfristigen
> Wahrnehmung hat sich MySQL von einer funktionsarmen und deswegen
> sauschnellen Datenbank (Version 2 konnte IIRC keine sub-selects, hat
> aber alle ehrwürdigen alten Damen wie z.B. Interbase bei den
> Antwortzeiten statisch aussehen lassen) zu einem ausgewachsenen
> DB-Server entwickelt, es aber irgendwie nie in die Liga der großen
> geschafft. Vielleicht weil immer noch der Schwerpunkt auf Einfachheit
> lag.
Das sauschnelle lag eher an den MyISAM Tabellen und galt auch nur im
> Am Wed, 21 Nov 2012 17:08:39 +0000 (UTC)
> schrieb Lutz Donnerhacke <lu...@iks-jena.de>:
>
>> * Marc Santhoff wrote:
>> > Und speziell zu MySQL: da es für seine Seltsamkeit bekannt ist,
>> > wird es nur noch in Ausnahmefällen unterstützt, nicht mehr als
>> > Standardfall.
>>
>> Echt? Es gibt Hoffnung? Ist der MySQL Treiber im PHP entgültig kaputt?
>
> Ich kann nur von mir selbst ausgehen, und in meiner langfristigen
> Wahrnehmung hat sich MySQL von einer funktionsarmen und deswegen
> sauschnellen Datenbank (Version 2 konnte IIRC keine sub-selects, hat
> aber alle ehrwürdigen alten Damen wie z.B. Interbase bei den
> Antwortzeiten statisch aussehen lassen) zu einem ausgewachsenen
> DB-Server entwickelt, es aber irgendwie nie in die Liga der großen
> geschafft. Vielleicht weil immer noch der Schwerpunkt auf Einfachheit
> lag.
Single-User-Mode (bzw. wenig Last generell). Skalieren tun ISAM-Tabellen
ziemlich schlecht.
Die fehlenden Subselects sind sicher zu bemängeln, aber viel schlimmer
finde ich, dass MyISAM keine Transaktionen unterstützt, was übrigens
Hand in Hand mit der guten Performance geht: wer kein WAL schreiben
muss, kann natürlich schneller sein. Nur sollte man da eben nicht
Äpfel mit Birnen vergleichen. Und wenn man INNODB als Engine
verwendet, verschwinden die Vorteile von MyISAM dann logischerweise
auch, aber dafür hat man dann auch eine vollwertige Datenbank mit
Transaktionen.
Ach so, eine weitere Kuriosität liegt an der Art und Weise, wie MySQL
die MyISAM-Tabellen implementiert hat: die Tabellen werden direkt auf
die entsprechenden Dateinamen des darunter liegenden BS abgebildet.
Unter Windows ist das Ok, aber unter Unix sind die Tabellennamen dann
mit einem Mal nicht mehr standardkonform case-sensitive ...
> Und da nun die Irritationen rund um offene Quellen dazu gekommen sind
> und auch noch Oracle Eigentümer ist ...
> Und was ist PHP, eine Palästinensische Politfraktion?
Bernd
--
no time toulouse
Stefan Froehlich
Nov 21, 2012, 2:02:22 PM11/21/12
to
On Wed, 21 Nov 2012 19:23:08 Bernd Nawothnig wrote:
> Ach so, eine weitere Kuriosität liegt an der Art und Weise, wie MySQL die
> MyISAM-Tabellen implementiert hat: die Tabellen werden direkt auf die
> entsprechenden Dateinamen des darunter liegenden BS abgebildet. Unter
> Windows ist das Ok, aber unter Unix sind die Tabellennamen dann mit einem
> Mal nicht mehr standardkonform case-sensitive ...
Case-INsensitive sollten sie sein, standardkonform.
> Ach so, eine weitere Kuriosität liegt an der Art und Weise, wie MySQL die
> MyISAM-Tabellen implementiert hat: die Tabellen werden direkt auf die
> entsprechenden Dateinamen des darunter liegenden BS abgebildet. Unter
> Windows ist das Ok, aber unter Unix sind die Tabellennamen dann mit einem
> Mal nicht mehr standardkonform case-sensitive ...
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Stefan, so rot wie der Frust. Lust für's Leben!
(Sloganizer)
Andreas Scherbaum
Nov 21, 2012, 2:01:30 PM11/21/12
to
Marc Santhoff <m.san...@t-online.de> wrote:
>
> Ich kann nur von mir selbst ausgehen, und in meiner langfristigen
> Wahrnehmung hat sich MySQL von einer funktionsarmen und deswegen
> sauschnellen Datenbank (Version 2 konnte IIRC keine sub-selects, hat
> aber alle ehrwï¿œrdigen alten Damen wie z.B. Interbase bei den
>
> Ich kann nur von mir selbst ausgehen, und in meiner langfristigen
> Wahrnehmung hat sich MySQL von einer funktionsarmen und deswegen
> sauschnellen Datenbank (Version 2 konnte IIRC keine sub-selects, hat
> Antwortzeiten statisch aussehen lassen) zu einem ausgewachsenen
> DB-Server entwickelt,
Was ist denn eine ausgewachsene Datenbank? Welche Kriterien
> DB-Server entwickelt,
legt man dafï¿œr an?
Andreas Scherbaum
Nov 21, 2012, 2:00:32 PM11/21/12
to
>> Und speziell zu MySQL: da es fï¿œr seine Seltsamkeit bekannt ist, wird es
>> nur noch in Ausnahmefï¿œllen unterstï¿œtzt, nicht mehr als Standardfall.
>
> Echt? Es gibt Hoffnung? Ist der MySQL Treiber im PHP entgï¿œltig kaputt?
Nein. Und es gibt mittlerweile mehrere davon (native, PDO, AdoDB, ...)
>> nur noch in Ausnahmefï¿œllen unterstï¿œtzt, nicht mehr als Standardfall.
>
> Echt? Es gibt Hoffnung? Ist der MySQL Treiber im PHP entgï¿œltig kaputt?
Nein. Und es gibt mittlerweile mehrere davon (native, PDO, AdoDB, ...)
Bernd Nawothnig
Nov 21, 2012, 2:28:40 PM11/21/12
to
On 2012-11-21, Stefan Froehlich wrote:
> On Wed, 21 Nov 2012 19:23:08 Bernd Nawothnig wrote:
>> Ach so, eine weitere Kuriosität liegt an der Art und Weise, wie MySQL die
>> MyISAM-Tabellen implementiert hat: die Tabellen werden direkt auf die
>> entsprechenden Dateinamen des darunter liegenden BS abgebildet. Unter
>> Windows ist das Ok, aber unter Unix sind die Tabellennamen dann mit einem
>> Mal nicht mehr standardkonform case-sensitive ...
>
> Case-INsensitive sollten sie sein, standardkonform.
Klar, sind sie aber eben unter Linux nicht. Zumindest war es noch vor
> On Wed, 21 Nov 2012 19:23:08 Bernd Nawothnig wrote:
>> Ach so, eine weitere Kuriosität liegt an der Art und Weise, wie MySQL die
>> MyISAM-Tabellen implementiert hat: die Tabellen werden direkt auf die
>> entsprechenden Dateinamen des darunter liegenden BS abgebildet. Unter
>> Windows ist das Ok, aber unter Unix sind die Tabellennamen dann mit einem
>> Mal nicht mehr standardkonform case-sensitive ...
>
> Case-INsensitive sollten sie sein, standardkonform.
einigen Jahren so, als ich das mal getestet habe.
Lutz Donnerhacke
Nov 21, 2012, 4:26:16 PM11/21/12
to
>>> Und speziell zu MySQL: da es für seine Seltsamkeit bekannt ist, wird es
>>> nur noch in Ausnahmefällen unterstützt, nicht mehr als Standardfall.
>>
>> Echt? Es gibt Hoffnung? Ist der MySQL Treiber im PHP entgültig kaputt?
aufkehren.
>>> nur noch in Ausnahmefällen unterstützt, nicht mehr als Standardfall.
>>
>> Echt? Es gibt Hoffnung? Ist der MySQL Treiber im PHP entgültig kaputt?
>
> Nein. Und es gibt mittlerweile mehrere davon (native, PDO, AdoDB, ...)
Das ist gut. Divide and conquere: Ressourcen zersplittern und die Scherben
> Nein. Und es gibt mittlerweile mehrere davon (native, PDO, AdoDB, ...)
aufkehren.
Marc Santhoff
Nov 21, 2012, 4:55:03 PM11/21/12
to
Am Wed, 21 Nov 2012 20:01:30 +0100
schrieb Andreas Scherbaum <ads-...@wars-nicht.de>:
> Marc Santhoff <m.san...@t-online.de> wrote:
> >
> > Ich kann nur von mir selbst ausgehen, und in meiner langfristigen
> > Wahrnehmung hat sich MySQL von einer funktionsarmen und deswegen
> > sauschnellen Datenbank (Version 2 konnte IIRC keine sub-selects, hat
> > aber alle ehrwürdigen alten Damen wie z.B. Interbase bei den
Deswegen sprach ich nicht von allgemeinen Definitionen sondern meiner
persönlichen Wahrnehmung.
Ich habe beobachtet, daß sich MySQL von einer Art Hobbyprojekt mit dem
Hauptziel, klein, schnell und leichtgewichtig in Sachen
Ressourcennnutzung hin zu einer Universal-SQL-Datenbank entwickelt hat.
Ich spekuliere, daß dies mmit der Kommerzialisierung einher ging, kann
das aber nicht historisch belegen.
Marc
--
"Mein Name ist Olo, Hans Olo"
schrieb Andreas Scherbaum <ads-...@wars-nicht.de>:
> Marc Santhoff <m.san...@t-online.de> wrote:
> >
> > Ich kann nur von mir selbst ausgehen, und in meiner langfristigen
> > Wahrnehmung hat sich MySQL von einer funktionsarmen und deswegen
> > sauschnellen Datenbank (Version 2 konnte IIRC keine sub-selects, hat
> > Antwortzeiten statisch aussehen lassen) zu einem ausgewachsenen
> > DB-Server entwickelt,
>
> Was ist denn eine ausgewachsene Datenbank? Welche Kriterien
> legt man dafür an?
> > DB-Server entwickelt,
>
> Was ist denn eine ausgewachsene Datenbank? Welche Kriterien
Deswegen sprach ich nicht von allgemeinen Definitionen sondern meiner
persönlichen Wahrnehmung.
Ich habe beobachtet, daß sich MySQL von einer Art Hobbyprojekt mit dem
Hauptziel, klein, schnell und leichtgewichtig in Sachen
Ressourcennnutzung hin zu einer Universal-SQL-Datenbank entwickelt hat.
Ich spekuliere, daß dies mmit der Kommerzialisierung einher ging, kann
das aber nicht historisch belegen.
Marc
--
"Mein Name ist Olo, Hans Olo"
Stefan Froehlich
Nov 21, 2012, 7:16:52 PM11/21/12
to
On Wed, 21 Nov 2012 20:28:40 Bernd Nawothnig wrote:
> >> unter Unix sind die Tabellennamen dann mit einem Mal nicht mehr
> >> standardkonform case-sensitive ...
> > Case-INsensitive sollten sie sein, standardkonform.
> Klar, sind sie aber eben unter Linux nicht.
Jetzt, wo Du es sagst, faellt mir auf, dass man Deinen Satz auf zwei
> >> unter Unix sind die Tabellennamen dann mit einem Mal nicht mehr
> >> standardkonform case-sensitive ...
> > Case-INsensitive sollten sie sein, standardkonform.
> Klar, sind sie aber eben unter Linux nicht.
unterschiedliche Arten interpretieren kann. Ich hatte nur die falsche
vor Augen (naemlich mit der Klammerung "nicht mehr [standardkonform
case-sensitive]").
> Zumindest war es noch vor einigen Jahren so, als ich das mal getestet
> habe.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Message has been deleted
Lutz Donnerhacke
Nov 23, 2012, 10:35:22 AM11/23/12
to
* Oliver Sch@d wrote:
>> Und was ist PHP, eine Palästinensische Politfraktion?
>
> Paralympischer HTML-Präprozessor.
>> Und was ist PHP, eine Palästinensische Politfraktion?
>
Ihrem Antrag auf Eintrag in die Fachbegriffe der Informatik wurde
kostenunpflichtig stattgegeben. Ihre Wartenummer ist 540.
0 new messages