PostgreSQL vs. MS SQL

[akretschmer]

http://www.pg-versus-ms.com/?utm_co...l&utm_source=facebook.com&utm_campaign=buffer

Was meint ihr dazu?

 

[Hony%]

Ich hab die Seite jetzt nur schnell überflogen. Wirkt ein wenig wie der alte Linux vs. Windows Krieg und hat den Geruch von »meiner ist länger als deiner!«.

Es gibt immer gute und schlechte Gründe für oder gegen ein System oder eine Software. Letztendlich ist die Entscheidung nicht selten eine Glaubensfrage oder richtet sich streng nach einem mehr oder weniger sinnvoll bestückten Anforderungskatalog.

 

[Walter]

Für mich ist das Betriebssystem-Argument fast das stärkste - warum sollte ich mich beim Datenbankserver an einen bestimmten OS-Hersteller binden?
Allerdings finde ich das mit count(*) bei PG extrem gruselig, das wusste ich noch gar nicht.

 

[ukulele]

Ich kenne mich ja hauptsächlich nur mit MS SQL Problemen aus und kann sicher nicht auf viel Erfahrung verweisen aber ich habs mal überflogen. Ich denke es gibt auch bei PG "Nachteile", die bleiben aber gänzlich unerwähnt. Man kann behaupten die gibt es nicht, das wirkt aber dann doch sehr glaubenslastig. Der ganze Text vergleicht nicht, er sucht sich alle "Problemzonen" bei MS SQL und schreibt, wie es PG besser macht. Auch würde ich nicht in allen Punkten übereinstimmen, das es sich um "Problemzonen" handelt.

zu 1.1)
CSV-Import habe ich sehr wohl schon vollzogen:

BULK
INSERT xxx_users
FROM 'D:\xxx\xxx_users.csv'
WITH
(
FIELDTERMINATOR = ';',
ROWTERMINATOR = '\n'
)
GO

Ich kann das nicht mit PG vergleichen, ist auch nicht mein Job. Erwähnt wird es aber nicht...

MS SQL Server silently truncating a text field

Habe ich noch nicht erlebt, mag aber Ausnahmen geben wo das stimmt. Ein Beispiel wird nicht genannt.

 

[akretschmer]

Allerdings finde ich das mit count(*) bei PG extrem gruselig, das wusste ich noch gar nicht.

Nun ja. Ja, das zieht einen Fulltablescan nach sich. Die Anzahl der sichtbaren Tupel kann ja in jeder Transaktion anders sein, dazu ist ein Blick auf XMIN/XMAX eines jeden Tupels nötig.

Es gibt aber auch Alternativen: oft reicht ein Näherungswert, dann kann man in pg_class schauen.