tntnet schrieb:
Im wesentlichen sind das doch Optimierungssachen. Und die verwendet man erst, wenn es wirklich notwendig ist. Und auch dann muss man abwägen, ob der Performancegewinn wirklich notwendig ist oder ob Portabilität wichtiger ist.
Die meisten Sachen: ja.
Bestimmte Dinge sind aber unglaublich praktisch, sparen also auch ordentlich Code. z.B. Arrays als Parameter übergeben zu können.
Bei anderen Dingen ist der Performance-Gewinn den man hat schnell mal Faktor 100 oder 1000 - z.B. beim Einfügen mehrerer Zeilen auf einmal mit MS-SQL. Das kann man dann oft nicht vernachlässigen.
tntnet schrieb:
Ich glaube, da hört meine spezifischen Kenntnisse über die Datenbanken auf, daher frage ich doch mal.
Ein clustered Index taucht doch in einer SQL-Abfrage nicht auf? Oder ein filtered Index? Da ergibt sich in der Applikation also kein Kompatibilitätsproblem.
In Abfragen nicht, aber natürlich im DDL. Je nachdem wie die Applikation installiert bzw. upgedated wird sind solche Statements dann auch in der Applikation selbst zu finden.
Und die Verfügbarkeit bzw. Nichtverfügbarkeit dieser Features verändert was man machen kann und was nicht. Bei einer DB die wie SQLite nur Nested Loops Joins kann, kann man bestimmte Abfragen auf bestimmte Tabellen mit bestimmten Inhalten einfach nicht machen (also nicht wenn man will dass sie auch irgendwann fertig werden). Wenn der Server dagegen Merge und/oder Hash Joins kann, dann kann man sie machen.
Ähnlich, wenn auch nicht ganz so krass, verhält es sich mit Clustered-Indexes oder Filtered-Indexes.
tntnet schrieb:
Optimizer hints braucht man in der Regel nicht. Die Datenbank optimiert in aller Regel sehr gut, bzw. gut genug.
Optimizer Hints braucht man nicht, so lange bis man sie eben doch braucht. Ich hab' einige Fälle erlebt wo der Optimizer einfach hin und wieder beschlossen hat "ab jetzt verwende ich einen anderen Plan", und dieser andere Plan hat dann SO viel länger gedauert dass ab da alle Clients in ein Timeout gelaufen sind, und im Prinzip nichts mehr gegangen ist. Nen genauen Slowdown-Faktor kann ich dir nicht sagen, aber in dem einen Fall sind Abfragen die davor so 1-2 Sekunden gedauert haben danach in ein Timeout gelaufen. Welches IIRC auf mehrere Minuten (schätze 5-10) eingestellt war. Also wirklich massiv, nicht "wir stellen nen schnelleren Server hin und gut".
Dann schreibt man 'nen Optimizer Hint rein.
tntnet schrieb:
In NVL oder ähnlichen Funktionen sehe ich keinen wirklichen Sinn. Das kann man problemlos in der Applikation behandeln.
Nicht wenn du es für z.B. nen JOIN brauchst. Bzw. auch bei Gruppierung oder in Aggregatfunktionen. Klar, man kann in der Applikation gruppieren und aggregieren etc., aber wieso etwas mühsam in C++/C#/Java ausprogrammieren was in SQL 2 Zeilen sind?
Gut, in C# wäre es dank LINQ auch nicht SO viel mehr Aufwand. In C++ würde ich aber ordentlich fluchen.
tntnet schrieb:
XML Spalten (oder JSON) kann man verwenden. Muss man aber nicht. Ich bevorzuge, solche Sachen in der Applikation zu behandeln. Eine normalisierte relationale benötigt das eigentlich nicht.
Wenn man sehr unterschiedliche Daten zu Objekten ablegen muss, sind XML Spalten praktisch. Klar kann man das alles in ein normalisiertes Modell aufdröseln, aber oft steht der Aufwand nicht dafür. Zumindest nicht wenn man ein DBMS verwendet das XML Spalten kann. In der Applikation kann man es machen, ja, aber nur wenn man nicht per Index in diesen XML-Schnippeln suchen muss. SQL Server kann das nämlich schön über nen XML-Index optimieren -- in der Applikation müsste man dafür nen Table-Scan machen. Oder nen externen XML-Index pflegen. Also entweder miese Performance oder wieder deutlicher Mehraufwand.
tntnet schrieb:
Parametrisierten prepared statements mit arrays sind sicher nett. Aber auch das kann man relativ leicht in der Applikation behandeln, indem man die Statements doch dynamisch zusammen baut. Sicher geht da ein wenig Performance verloren. Aber wieder muss man abwägen, ob die Portabilität nicht höher wiegt.
Ja klar muss man das abwägen. Ich sag' ja nicht dass Portabilität nicht wichtig ist. Ich sag' nur dass man Portabilität kaum erreichen kann wenn man sie nicht vorab testet. Weil es eben zu viele praktische Dinge gibt die sonst einfach verwendet werden.
So lange man alleine programmiert und selbst nicht in die Versuchung kommt non-Standard Sachen zu verwenden, und gut genug weiss welche Standard Features auch wirklich portabel sind (was ja wie gesagt nicht auf alle zutrifft), wird es kein Problem sein. Bei grösseren Projekten wo Entwickler kommen und gehen, und wo es keine dahingehenden Tests gibt, schätze ich die Chance dass sich keine nicht-portablen Konstrukte einschleichen aber sehr gering ein. Das wollte ich sagen. Nicht mehr und nicht weniger.
