Über Sinn und Unsinn von Softwareempfehlungen, die der TE nicht nutzt

[Perry Staltic]

Mir wurde gestern empfohlen, einen eigenen Thread für diese Diskussion zu starten. Also denn:

Primär geht es um die Frage, wie hilfreich Hinweise sind, Probleme des TE derart zu lösen, dass man nicht ein gutes, richtiges Vorgehen im Szenario des Thread vorschlägt, sondern eine andere Software(komponente), die besser ist. Das Problem kennen wahrscheinlich einige und es hat offenbar das Potential, mit einem Satz Glaubenskriege ala Apple/Android o.ä. auszulösen.

Interessant ist dabei folgender Gedanke:

Grundsätzlich antworte ich auf eine PHP-Frage auch nicht mit Perl-Lösungen, nur weil ich es geiler finde!

Es ist offensichtlich totaler Quatsch, in einem PHP Forum mit Perl Lösungen aufzukreuzen. Das entspricht aber nicht unbedingt der Situation, um die es geht.

Nehmen wir bspw. PDO statt veralteter Zugriffskomponenten. Da würde jeder sagen, Recht hat er, oder? Klar, wir reden von einem austauschbaren (nicht unbedingt beliebigen) "Hilfsmittel". Ähnliches könnte man wahrscheinlich von vielen Modulen sagen und die spannende Frage ist oft, welche der Alternativen ist denn nun die beste. Nicht dass genau das die TE Frage wäre, der TE kennt die Alternative vielleicht gar nicht und quält sich mit einer denkbar schlechten rum.
Kann man nicht analog Postgres und mySQL hier in dem Beispiel einsetzen?

Es geht mir nicht darum zu klären, welches der beiden Systeme nun wirklich das bessere ist. Das ist generell sicher nicht eindeutig zu klären. Es geht um die Berechtigung dieses Vorschlags. Was macht den Unterschied?

[hellbringer]

Eigentlich geht es hier um Planungsfehler. Man sollte seine Komponenten passend zu den Aufgaben wählen und nicht umgekehrt seine Komponenten so weit umbiegen, dass sie die Aufgabe erfüllen können.

Das Problem ist, dass viele unerfahrene Programmierer keinen Überblick haben und somit die Planung gegen Null geht. Man nimmt PHP, weil es einfach erlernbar ist und von den Hostern breit unterstützt wird. Man nimmt MySQL, weil es praktisch bei jedem PHP-Hoster dabei ist und weil 99,99% der PHP-Tutorials auf MySQL basieren, nicht weil es ein gutes DBMS ist. Ob das jetzt für die geplante Anwendung Sinn ergibt, wird hier nicht hinterfragt.

Das Schwierige ist jetzt die Planungsfehler anzusprechen. Wie bringt man den Programmierer dazu auf seinem Weg zwei Schritte zurück zu machen, damit er die richtige Abzweigung nimmt? Er hat schon viel Zeit in seinen Weg investiert. Wie viel Nachdruck muss oder darf man geben? Oder wäre es nicht besser ihn auf seinem schwierigen Weg zu unterstützen, in der Hoffnung, dass er daraus lernt und beim nächsten mal die richtige Abzweigung nimmt?

Die Situation bei der mysql-Extension ist vollkommen klar. Diese ist praktisch tot und es fehlen viele Features, die im Programmieralltag hilfreich sind. Ich kann mir kein Anwendungsszenario vorstellen, wo die mysql-Extension benötigt wird.

MySQL reicht für einfache Dinge aus. Es laufen viele Anwendungen vollkommen problemlos mit MySQL. Die Sache ist, dass man recht schnell an die Grenzen von MySQL stoßen kann. Meiner Ansicht nach reicht es hier ein anderes DBMS erst dann zu empfehlen, wenn absehbar ist, dass diese Grenzen erreicht sind oder recht bald erreicht werden.

[raptor49]

MySQL reicht für einfache Dinge aus. Es laufen viele Anwendungen vollkommen problemlos mit MySQL. Die Sache ist, dass man recht schnell an die Grenzen von MySQL stoßen kann. Meiner Ansicht nach reicht es hier ein anderes DBMS erst dann zu empfehlen, wenn absehbar ist, dass diese Grenzen erreicht sind oder recht bald erreicht werden.

Wenn es gilt die Grenze zu übertreten, kommt doch gleich eine Oracle DB zum tragen oder gar MS etc. Wobei wir dann auch gleich bei den Entwicklungskosten und der Planung wären. Dann käme womöglich auch gar nicht PHP zum Einsatz sondern Python oder Java.

[Arne Drews]

Hallo,

Primär geht es um die Frage, wie hilfreich Hinweise sind, Probleme des TE derart zu lösen, dass man nicht ein gutes, richtiges Vorgehen im Szenario des Thread vorschlägt, sondern eine andere Software(komponente), die besser ist. Das Problem kennen wahrscheinlich einige und es hat offenbar das Potential, mit einem Satz Glaubenskriege ala Apple/Android o.ä. auszulösen.

Es ist absolut legitim, Empfehlungen zu anderer Software und anderen Möglichkeiten zu geben, das hat auch niemand verboten oder als falsch bezeichnet!

Anders verhält es sich allerdings, wenn dem TE ausschliesslich Lösungen geboten werden, die mit der von ihm eingesetzten Software-Basis wohl wissend nicht funktioniert! Wem bitte hilft das an irgendeiner Stelle? Der Thread, der als Basis dieses gilt, wurde geschlossen weil die weiterführende Diskussion nichts mehr mit dem Thema zu tun hatte. In diesem und fast allen anderen Foren gilt i.d.R.: Ein Thread = ein Thema! Wer nachlesen möchte, es geht um diesen Thread: https://www.php.de/forum/webentwickl...ln-performance, wobei die Seite 2 in Bezug auf diesen Thread ausschlaggebend ist.

Es ist offensichtlich totaler Quatsch, in einem PHP Forum mit Perl Lösungen aufzukreuzen. Das entspricht aber nicht unbedingt der Situation, um die es geht.

Doch, eigentlich geht es genau darum. Viele kompetente Mitglieder hier im Forum vergessen oft, dass viele Anfänger/Einsteiger nicht die Möglichkeit haben, sich - um bei dem Beispiel aus dem Ursprungsthread zu bleiben - pgSQL zu installieren. Was soll der TE dann mit Lösungsvorschlägen, die einfach nur deutlich machen, dass pgSQL besser ist und MySQL es auf die Art und Weise nicht kann?! Das sind absolute Schwachsinnsantworten und ich weiß, dass diese nicht von Dir gekommen sind, es soll nur verdeutlichen, worum es bei der Schliessung wirklich ging, denn das hast Du hier ein wenig aus dem Zusammenhang gerissen.

Nehmen wir bspw. PDO statt veralteter Zugriffskomponenten. Da würde jeder sagen, Recht hat er, oder? Klar, wir reden von einem austauschbaren (nicht unbedingt beliebigen) "Hilfsmittel". Ähnliches könnte man wahrscheinlich von vielen Modulen sagen und die spannende Frage ist oft, welche der Alternativen ist denn nun die beste. Nicht dass genau das die TE Frage wäre, der TE kennt die Alternative vielleicht gar nicht und quält sich mit einer denkbar schlechten rum.

Absolut richtig, aus meiner Sicht.

Kann man nicht analog Postgres und mySQL hier in dem Beispiel einsetzen?

Nein, kann man eben nicht!
pgSQL und MySQL hat beides nichts mit "veraltet" zu tun! Zudem gibt es Hoster, wie bspw. Strato, die selbst im größten Webspace-Paket nur MySQL anbieten. Erkläre mir bitte, welchen Sinn dann pgSQL haben soll für den TE?! Er wird sicher nicht aufgrund der Antworten seinen Hoster wechseln. Im Gegenteil, er wird eher frustriert sein von dem Forum, weil man ihm bei seinem Problem nicht helfen "will".

Wenn ein TE nach einer Lösung für ein SQL-Problem fragt, ist auch pgSQL absolut gerechtfertigt, selbst T-SQL könnte man dann anbieten.
Ist aber bekannt, dass der TE MySQL oder sqlite nutzt, macht es einfach keinen Sinn, pg-Lösungen anzubieten, die so nicht auf MySQL oder sqlite übertragbar sind. In dem Fall kann man sich auch einfach mal eine Antwort sparen.

Es geht mir nicht darum zu klären, welches der beiden Systeme nun wirklich das bessere ist. Das ist generell sicher nicht eindeutig zu klären.

Ich denke schon, denn allgemein ist wohl pgSQL das bessere System, wenn ich das beurteilen sollte.

Es geht um die Berechtigung dieses Vorschlags. Was macht den Unterschied?

Der Unterschied ist der, dass dem TE nicht geholfen ist, wenn man Vorschläge macht, die er nicht nachvollziehen oder umsetzen kann! Wenn ihr so clever seid, könnt ihr doch auch Möglichkeiten für das vom TE verwendete System anbieten?! Oder man fragt den TE, ob er die Möglichkeit hat zu wechseln. Wenn ja, könnt ihr alles raushauen, was - in diesem Fall - pg alles kann. Ansonsten, einfach mal einen Beitrag weniger, das hilft dem TE deutlich mehr.

Das Problem ist, dass viele unerfahrene Programmierer keinen Überblick haben und somit die Planung gegen Null geht. Man nimmt PHP, weil es einfach erlernbar ist und von den Hostern breit unterstützt wird. Man nimmt MySQL, weil es praktisch bei jedem PHP-Hoster dabei ist und weil 99,99% der PHP-Tutorials auf MySQL basieren, nicht weil es ein gutes DBMS ist. Ob das jetzt für die geplante Anwendung Sinn ergibt, wird hier nicht hinterfragt.

Das wären auch aus meiner Sicht die typischen "Anfänger"-Konstellationen. Und ich finde es ganz wichtig, dies als Helfender zu bedenken, wenn man antworten und helfen will!

MySQL reicht für einfache Dinge aus. Es laufen viele Anwendungen vollkommen problemlos mit MySQL. Die Sache ist, dass man recht schnell an die Grenzen von MySQL stoßen kann. Meiner Ansicht nach reicht es hier ein anderes DBMS erst dann zu empfehlen, wenn absehbar ist, dass diese Grenzen erreicht sind oder recht bald erreicht werden.

Auch korrekt aus meiner Sicht. Wobei es oft auch alternative Möglichkeiten mit MySQL gibt, auch wenn sie komplizierter sind, als mit anderen DBMS.

Was den Grundgedanken dieses Threads angeht:

Primär geht es um die Frage, wie hilfreich Hinweise sind, Probleme des TE derart zu lösen, dass man nicht ein gutes, richtiges Vorgehen im Szenario des Thread vorschlägt, sondern eine andere Software(komponente), die besser ist.

ist das aus meiner Sicht abschliessend nicht pauschal zu beantworten. Ich selber verzichte bspw. weitesgehend auf JS-Bibliotheken oder -Frameworks. Viele Fragen, die scheinbar mit jQuery gelöst werden "wollen", lassen sich relativ einfach mit purem JS lösen und dann biete ich das auch so an! Aber ich schlage nichts vor, was jQuery in dem Fall nicht könnte...

Gruß Arne

[rkr]

Wenn es gilt die Grenze zu übertreten, kommt doch gleich eine Oracle DB zum tragen oder gar MS etc. Wobei wir dann auch gleich bei den Entwicklungskosten und der Planung wären. Dann käme womöglich auch gar nicht PHP zum Einsatz sondern Python oder Java.

MySQL ist ein relativ kaputtes Produkt. Im Verhältnis dazu ist PostgreSQL relativ heil.
Es gibt außer MySQL noch andere freie Datenbankprodukte wie MongoDB, Riak, Neo4J, CouchDB, OrientDB, XML-Datenbanken, SQLite, Cassandra, ElasticSearch/Solr/Lucene oder Firebase.

Oder lass und besser über Datenbankkonzepte sprechen:
- SQL
- Key-Value
- Document-Stores
- Graphen-DB
- Column-DB

Wer als Alternative zu MySQL nur Oracle oder MS-SQL im Sinn und auch nie etwas anderes verwendet hat, sollte anderen wahrscheinlich keine Ratschläge in diesem Bereich geben.

[VPh]

Kann man nicht analog Postgres und mySQL hier in dem Beispiel einsetzen?

Kann man IMO machen. Es geht aber auch darum wie man es macht.

"Hey, das geht in MySQL (so hier / gar nicht).... Aber guck mal wie einfach das stattdessen in PostgreSQL funktionieren würde:..."
ist etwas anderes als
"Lol was nutzt du denn für eine Schrott-DB. Guck mal hier, mit PostgreSQL kannst du BigDick-Mode gehen:..., geil oder?"

Und auch mit der ersten Variante reicht 1 Hinweis pro Thread oder gar pro TE. Man muss einem nicht ständig unter die Nase reiben, dass eine andere Komponente besser ist; vielleicht gibt es ja Gründe aus denen der TE nicht wechseln kann.

[Perry Staltic]

Planungsfehler

Es sind ja meist sehr unterschiedliche Anfragen, von Hobby, über Enthusiast bis Profi. In allen 3 Bereichen kommen Planungsfehler leider vor, oft kann man vielleicht von Planung gar nicht sprechen. Es geht nur um Spaß an der Freude.

Wann lässt sich da eine Empfehlung (für einen DB Schwenk) ausschließen? Bei einem produktiven, komplexen Projekt, dass ggf. durch das Hosting limitiert ist? Erkennt man das ohne weiteres an den Aussagen des TE?

(funktionale) Grenzen erreicht

Tatsächlich ist es ja so, dass gerade im Datenbankforum diese Grenzen durchaus häufig erreicht sind/scheinen. Alternativen sind dann eben/scheinbar wilde SQL Konstrukte, die berühmte Whileschleife in PHP...

(Kommerzielle) Alternativen

Es steht natürlich jedem frei, Geld für eine DB auszugeben. Sobald man von einem Webprojekt redet, sind das aber ziemliche Summen, die man bei Einhaltung der Lizenzbestimmungen ausgeben muss (Cloudvarianten, SaaS. .. mal außen vor) Zu PHP passen kostenfreie DB ganz gut finde ich.

Forenregeln

Es geht mir weniger um die Forenregeln, die sind einzuhalten. Das will ich auch gar nicht in Frage stellen. In der Praxis ist es aber schon so, dass im Verlauf eines Threads auch Randthemen usw. am einfachsten im Thread selbst genannt werden können, es ist halt bequem und naheliegend.

Ich persönlich bin kein großer Freund davon, sowas besonders akribisch durchzuziehen oder sagen wir so, ich sehe da einen Ermessensspielraum, den andere (Moderatoren z.B.) nicht sehen, it depends. Stackoverflow lässt grüßen. Ich beschäftige mich lieber mit der Sache, mglw auch mit einer Nebensache, als mit Formalitäten oder irgendwelchen Punktesammelaktionen zwecks Erwerb des Rechtes auf grundlegende Forenfunktionen. Aber das ist wieder ein anderes Thema.

Letztlich sind hier meist erwachsene Menschen am Start, man sollte über alles reden können, hoffe ich eigentlich.

"Es geht genau darum"

Oft hat der TE keine Wahl und der Vorschlag, eine andere DB zu nehmen nervt dann (da schließe ich mich selber ein). Das ist allerdings nicht immer offensichtlich. Im auslösenden Thread war/ ist es m.E. anders, ein Raspberry Pi kann postgres, mysql, sqlite usw. Der TE könnte mit einem Einzeiler postgres installieren. Aber egal, wenn ein solcher Vorschlag grundsätzlich erstmal legitim ist, wo ist die Grenze, wo ist der "Schwachsinn"?


mySQL Extension/PDO versus mySQL/postgres
Allein das Bekanntsein, dass ein TE ein bestimmtes Softwaremodul nutzt, kann nicht der Grund für das Verschweigen besserer Lösungen sein. Und ich bin mir ziemlich sicher, dass es meist auch nicht so praktiziert wird.
Der Vergleich mit mysql-Extension/PDO hinkt vielleicht, weil es wirklich ein totes Pferd ist, es ließen sich bessere Analogien finden, aber es ändert nichts am Prinzip.

Wenn ihr so clever seid, könnt ihr doch auch Möglichkeiten für das vom TE verwendete System anbieten?!

Dieser Vermutung erliegt sicher auch der ein oder andere TE. Und bevor man seine eigene Welt in Frage stellt, bekommt man es mit einem komplexen SQL, auf das man evtl. nie gekommen wäre, vielleicht doch hin. Ist das nun eine Hilfe oder ist das Verschleierung eines Problems(Planungsfehler)?

Vielleicht ist ja der Tipp ein anderes Modul zu nutzen viel schlauer, als er einem/dem TE auf den ersten Blick erscheint, (der Schein trügt vielleicht besonders, gerade wenn/weil man einen "Workaround" in der eigenen Welt serviert bekommt)

Datenbankkonzepte

Konzepte zu diskutieren, wäre natürlich die beste Voraussetzung, Planungsfehler zu vermeiden und eine möglichst gute Wahl für sein Projekt zu treffen. Das dürfte bei Neulingen selten die Herangehensweise sein. Ich denke, dazu gehört schon eine gewisse Kenntnis der Materie oder das blinde Vertrauen eines Anfängers auf eine gute Empfehlung.

Es geht um das wie

Scheint mir aus verschiedenen Gründen sinnvoll.
Denn bis jetzt habe ich keinen Punkt gefunden, wo man einigermaßen klar festmachen kann, ab hier geht's zu weit.

Einerseits bin ich selbst manchmal genervt von besagten Hinweisen, andererseits hab ich nichts dagegen, meinen Horizont zu erweitern. Hilfe ala "Du kanst das so machen und zwar konkret so .. , aber es gäbe elegantere, robustere, einfachere .. Möglichkeiten.." würde ich favorisieren.