DB2 hat micht nicht sehr begeistert.

[exs]

Wir hatten damit kurz im Studium zu tun. Möglicherweise ist es für "skalierbare Enterprise-Lösungen" zu gebrauchen, aber sehr entwicklerfreundlich ist es nicht.

[Ich&Du]

exs schrieb:
-------------------------------------------------------
> Wir hatten damit kurz im Studium zu tun.
> Möglicherweise ist es für "skalierbare
> Enterprise-Lösungen" zu gebrauchen, aber sehr
> entwicklerfreundlich ist es nicht.

Dann hast Du leider keine Ahnung. DB2 ist aeusserst entwicklerfreundlich da sich DB2 an den SQL Standard haelt und nicht wie Oracle eigene Geschichten hinzudichtet (varchar2, falsches runden => dividiere doch 'mal 99'999'999, typ numeric(10), durch 1'000 und staune was du bekommst , kein boolean, keine Info-Tabellen, keine leeren Texte wenn NOT NULL constraint gesetzt) oder weglaesst (kein limit zbsp.)

Als Entwickler gibt es nur eines: Entweder DB2 oder PostgreSQL. Alles andere fuehrt am Ende nur in einen Lock-In, der erstens teuer ist, zweitens unflexibel und drittens verdammt unschoen bei einer Migration ist.

[exs]

Ich&Du schrieb:
>
> Dann hast Du leider keine Ahnung. DB2 ist
> aeusserst entwicklerfreundlich da sich DB2 an den
> SQL Standard haelt und nicht wie Oracle eigene
> Geschichten hinzudichtet (varchar2, falsches

Vielleicht hast du Recht -- ich bin sonst überhaupt kein großer Datenbankdesigner.

Aber was mich zum Beispiel enorm gestört hat: man kann keine Offsets aus dem ergebnis einfach heraussuchen (es gibt nur FETCH FIRST X ROWS ONLY), keine Möglichkeit Tabellenfelder zu löschen (ALTER TABLE DROP ... funktioniert einfach nicht!), Shell-Frontend sehr unkomfortabel.

> Als Entwickler gibt es nur eines: Entweder DB2
> oder PostgreSQL. Alles andere fuehrt am Ende nur

Postgre find' ich auch gut, aber DB2 hatte mir zu viele Macken/Eigenheiten...

[OMG]

> Aber was mich zum Beispiel enorm gestört hat: man
> kann keine Offsets aus dem ergebnis einfach
> heraussuchen (es gibt nur FETCH FIRST X ROWS
> ONLY), ...

Lol, genau das Problem hatten wir auch kürzlich.

[Ich&Du]

exs schrieb:

>
> Aber was mich zum Beispiel enorm gestört hat: man
> kann keine Offsets aus dem ergebnis einfach
> heraussuchen (es gibt nur FETCH FIRST X ROWS
> ONLY), keine Möglichkeit Tabellenfelder zu löschen
> (ALTER TABLE DROP ... funktioniert einfach
> nicht!), Shell-Frontend sehr unkomfortabel.
>

http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/QB3AQ902/5.4.3?SHELF=&DT
http://troels.arvin.dk/db/rdbms/#select-limit

[JTL]

Ich&Du schrieb:
-------------------------------------------------------
> exs schrieb:
> --------------------------------------------------
> -----
> > Wir hatten damit kurz im Studium zu tun.
>
> Möglicherweise ist es für "skalierbare
>
> Enterprise-Lösungen" zu gebrauchen, aber sehr
>
> entwicklerfreundlich ist es nicht.
>
> Dann hast Du leider keine Ahnung. DB2 ist
> aeusserst entwicklerfreundlich da sich DB2 an den
> SQL Standard haelt und nicht wie Oracle eigene
> Geschichten hinzudichtet (varchar2, falsches
> runden => dividiere doch 'mal 99'999'999, typ
> numeric(10), durch 1'000 und staune was du
> bekommst , kein boolean, keine Info-Tabellen,
> keine leeren Texte wenn NOT NULL constraint
> gesetzt) oder weglaesst (kein limit zbsp.)
>
> Als Entwickler gibt es nur eines: Entweder DB2
> oder PostgreSQL. Alles andere fuehrt am Ende nur
> in einen Lock-In, der erstens teuer ist, zweitens
> unflexibel und drittens verdammt unschoen bei
> einer Migration ist.



Vorsicht, wer andere ahnungslos schimpft, sollte umso mehr auf seine Aussagen achten. Limit z.B. ist _kein_ SQL-Standard, im Gegenteil. Ich verstehe auch gerade nicht, warum man "leere Texte" in NOT NULL-Feldern schreiben können soll ...? Genau das soll NOT NULL doch verbieten?

[Naja]

"Lock-in"... Naja, nachdem man was-weiss-ich-wieviel kEuro fuer eine Datenbank ausgegeben hat, kann man diese auch so gut wie moeglich ausnutzen. Sonst brauche ich wirklich kein DB2 oder Oracle. Dann lieber eine DB voll ausreizen und deren Vorteile nutzen, seien sie auch proprietaer.

[Constraint]

Allerdings... Immer diese dummen Constraints! ;)

[Foxfire]

> ist _kein_ SQL-Standard, im Gegenteil. Ich
> verstehe auch gerade nicht, warum man "leere
> Texte" in NOT NULL-Feldern schreiben können soll
> ...? Genau das soll NOT NULL doch verbieten?

Weil das zwei komplett verschiedene Sachen sind??

Es ist doch auch ein Unterschied, ob ich einen leeren Kühlschrank habe, oder gar keinen Kühlschrank.
Gerade mit objektrelationalen Erweiterungen ist das bitter nötig. Aber auch ohne macht "" == null absolut keinen Sinn.

[DerMuedeJo]

In der Firma, in der ich arbeite, werden DB2 Datenbanken auf OS390 Servern betrieben mit riesigen Datenmengen. Wenn man sich an die Standards hält, geht das super. Und wenn das jetzt auch für kleinere Rechner effektiv nutzen lässt( ohne zus. Kosten ), bin ich sehr damit einverstanden.


exs schrieb:
-------------------------------------------------------
> Wir hatten damit kurz im Studium zu tun.
> Möglicherweise ist es für "skalierbare
> Enterprise-Lösungen" zu gebrauchen, aber sehr
> entwicklerfreundlich ist es nicht.

[JTL]

Foxfire schrieb:
-------------------------------------------------------
> > ist _kein_ SQL-Standard, im Gegenteil.
> Ich
> verstehe auch gerade nicht, warum man
> "leere
> Texte" in NOT NULL-Feldern schreiben
> können soll
> ...? Genau das soll NOT NULL doch
> verbieten?
>
> Weil das zwei komplett verschiedene Sachen sind??
>
> Es ist doch auch ein Unterschied, ob ich einen
> leeren Kühlschrank habe, oder gar keinen
> Kühlschrank.
> Gerade mit objektrelationalen Erweiterungen ist
> das bitter nötig. Aber auch ohne macht "" == null
> absolut keinen Sinn.

Vielleicht sollten wir leer näher definieren. Für mich war leer jetzt == null, nicht "". Man kann bei Oracle zumindest null-Werte nicht in NOT NULL-Feldern speichern, aber sehr wohl ""-Werte.

[FB]

JTL schrieb:
-------------------------------------------------------
> Foxfire schrieb:
> --------------------------------------------------
> -----
> > > ist _kein_ SQL-Standard, im
> Gegenteil.
> Ich
> verstehe auch gerade
> nicht, warum man
> "leere
> Texte" in NOT
> NULL-Feldern schreiben
> können soll
> ...?
> Genau das soll NOT NULL doch
> verbieten?
>
> Weil das zwei komplett verschiedene Sachen
> sind??
>
> Es ist doch auch ein
> Unterschied, ob ich einen
> leeren Kühlschrank
> habe, oder gar keinen
> Kühlschrank.
>
> Gerade mit objektrelationalen Erweiterungen
> ist
> das bitter nötig. Aber auch ohne macht ""
> == null
> absolut keinen Sinn.
>
> Vielleicht sollten wir leer näher definieren. Für
> mich war leer jetzt == null, nicht "". Man kann
> bei Oracle zumindest null-Werte nicht in NOT
> NULL-Feldern speichern, aber sehr wohl ""-Werte.
>
>

NULL != ""

[TimTim]

exs schrieb:
-------------------------------------------------------

> keine Möglichkeit Tabellenfelder zu löschen
> (ALTER TABLE DROP ... funktioniert einfach
> nicht

Wie du einem meiner Vorredner (Vorschreiber???) bereits entnehmen konntest, gibt es anscheinend in DB2 dafür doch ein Statement. Ich denke aber man sollte vor dem Entwerfen einer Tabelle über die Felder Gedanken machen. Ich hab zumindest in meiner Programmiererlaufbahn noch nie ein Feld in einer Datenbank löschen müssen. Schön wenns geht, aber ich brauche das nicht.

[Pümpel]

JTL schrieb:
-------------------------------------------------------

> Vorsicht, wer andere ahnungslos schimpft, sollte
> umso mehr auf seine Aussagen achten. Limit z.B.
> ist _kein_ SQL-Standard, im Gegenteil.

Äh. Genau DAS hat er doch geschrieben. Erst verstehen, dann antworten ...

[Ich&Du]

FB schrieb:
-------------------------------------------------------
> JTL schrieb:
> --------------------------------------------------
> -----
> > Foxfire schrieb:
>
> --------------------------------------------------
>
> -----
> > > ist _kein_
> SQL-Standard, im
> Gegenteil.
> Ich
>
> verstehe auch gerade
> nicht, warum man
>
> "leere
> Texte" in NOT
> NULL-Feldern
> schreiben
> können soll
> ...?
> Genau
> das soll NOT NULL doch
> verbieten?
>
> Weil das zwei komplett verschiedene
> Sachen
> sind??
>
> Es ist doch auch
> ein
> Unterschied, ob ich einen
> leeren
> Kühlschrank
> habe, oder gar keinen
>
> Kühlschrank.
>
> Gerade mit
> objektrelationalen Erweiterungen
> ist
> das
> bitter nötig. Aber auch ohne macht ""
> ==
> null
> absolut keinen Sinn.
>
> Vielleicht sollten wir leer näher definieren.
> Für
> mich war leer jetzt == null, nicht "".
> Man kann
> bei Oracle zumindest null-Werte
> nicht in NOT
> NULL-Feldern speichern, aber
> sehr wohl ""-Werte.
>
> NULL != ""
>
>

Danke Jungs, gibt ja doch noch ein paar die DB's wirklich schnallen. Lasst euch nicht von den Oracle-Weicheiern einlullen! Muesst ihr fuer eine grosse DB planen nehmt DB2, laeufts auch ohne Mainframe/Cluster-PC's, dann nehmt ihr doch bitte PostgreSQL. Aber NIE NIE NIE Oracle ;-)