mysql - postgresql

[rEmix]

hi

ich hab für mein projekt "gezwungenermaßen" psql benutzt. jetzt stell ich mir aber schon die ganze zeit die frage, warum wir überhaupt komplett auf psql umstellen.

hirngespinnst meines chefes?

seine antwort "es kann mehr"

ja fein, aber was genau kann er mir auch nich sagen.

bin mir ziemlich sicher dass mich die prüfer fragen, warum ich überhaupt von mysql auf psql umgestiegen bin. reicht da als antwort "kompletter betrieb stellt auf psql um" ?

wollte in meiner präsi schreiben, dass mysql KEINE trigger + vererbung unterstützt bzw erst ab version 5. nun find ich aber immer andere daten, wann mysql 5 erschien....

kurz:

a) argumente FÜR postgresql gegenüber mysql

wann erschien mysql 5

danke & gruß

[lordy]

Zum Thema Release-Date kann ich folgendes aus meinem Mail-Archiv anbieten:

Datum: Do, 25.12.2003, 04:17

Betreff: [fmII] MySQL Database Server 5.0.0 released (Development (5.0.x) branch)

Alle Angaben ohne Gewähr

[Amstelchen]

wollte in meiner präsi schreiben, dass mysql KEINE trigger + vererbung unterstützt bzw erst ab version 5.

trigger werden von mysql ab 5.0.2 unterstützt. so gesehen hast du recht.

nun find ich aber immer andere daten, wann mysql 5 erschien....

siehe changelog von mysql unten.

a) argumente FÜR postgresql gegenüber mysql

- geschachtelte subselects

- beschreibbare views

- IMHO bessere triggerunterstützung als mysql

- IMHO bessere unterstützung von stored procedues (ähnlich PL/SQL external procedures bei oracle)-

wann erschien mysql 5

http://dev.mysql.com/doc/refman/5.0/en/news-5-0-x.html

es existiert im übrigen ein recht informativer thread hierüber.

s'Amstel

[rEmix]

wunderbar, danke.

aus dem von dir genannten thread werd ich aber nicht schlauer.

oke, denke das argument ist korrekt:

zur projekt-bearbeitungs-zeit unterstützte die zu dem zeitpunkt aktuellste mysql version keine trigger. die version erschien am 31. märz 2006, in meiner doku steht, dass ich am 31.märz und den darauffolgenden tagen schon die doku geschrieben habe, woraus folgt, dass das projekt an sich schon abgesclossen war. ende.

thx

[Jaraz]

Postgresql kostet definitiv nix.

Mysql eventuell schon.

http://www.mysql.de/company/legal/licensing/

Gruß Jaraz

[isardor]

Der Create Tavle string in Postresql ist kürzer

MySQL: create table foo (id int not null auto_increment primary key,...)

Postgres: create table foo (id serial primary key,...)

[Amstelchen]

Der Create Tavle string in Postresql ist kürzer

MySQL: create table foo (id int not null auto_increment primary key,...)

Postgres: create table foo (id serial primary key,...)

aber auch nur, weil du NOT NULL bei mysql nicht hingeschrieben hast und AUTO_INCREMENT bei postgres SERIAL heisst. definiere mal bitte "kürzer".

http://www.postgresql.org/docs/8.1/static/sql-createtable.html

http://dev.mysql.com/doc/refman/5.0/en/create-table.html

s'Amstel

[isardor]

Nun kürzer in dem Sinne, dass man für einfache Tabellen weniger Zeitaufwand benötigt, weil es weniger Schreibarbeit ist. Und zeitaufwand darf man in einem Projekt nie unterschätzen. Aber ansonsten hast du schon recht, 'nur' weil 'int not null auto_increment' wegfällt und stattdessen nur 'serial' geschrieben werden muss ist der string nicht sonderlich kürzer.

Oh sehe grade:

Ich denke das hast du falsch verstanden, SERIAL deckt INT NOT NULL AUTO_INCREMENT komplett ab, ich habe NOT NULL nicht vergessen.

[Jaraz]

Mit Verlaub, aber die Länge irgendwelcher Statements als positiv oder negativ für irgendwelche Datenbanken zu nehmen, ist imho so wichtig wie eine geplatzte Bratwurst in Bottrop.

Gruß Jaraz

PS: Ich tippe schon seit Jahren keine DDL Statements mehr, sondern lasse sie generieren.

[isardor]

PS: Ich tippe schon seit Jahren keine DDL Statements mehr, sondern lasse sie generieren.

Interessant, und welchest Tool nimmst du dafür?

PS.: War noch nie in Bottrop