Wie wichtig ist SQL

[lokked]

zeige, dass du lern-willig bist.

Ich glaube das ist das Problem ^^

 

[BTCStorage]

Du machst das also nur wegen irgendeinem Zertifikat?
Was erhoffst du dir damit?
Warst du jetzt ein Jahr arbeitslos in diesen Zeiten? Viele Firmen suchen händeringend Leute. Auch wir haben bis vor kurzem noch massiv Java-/Frontend-Programmierer gesucht.
Mach doch bei einer Firma ein Praktikum (bezahlt vom Arbeitsamt und der Firma) und zeige, was du kannst bzw. zeige, dass du lern-willig bist.

Mir scheint, als hättest du keine Zukunftspläne. Ansonsten hättest du bewusst eine Programmiersprache ausgewählt, die dich besonders interessiert und die bei deiner Wunschfirma auch verwendet wird.
Ich möchte jetzt PHP nicht schlecht reden, aber ich hätte PHP ganz sicher nicht genommen. Im professionellen Umfeld wird viel mehr mit Java und .Net gearbeitet. Vermutlich wirst du aber von solchen Firmen gar nicht genommen. Ohne Studium ist das schwer.

Arbeitsamt wollte ja das ich den Kurs mache.
Ich selber baue paar Sachen und benutze das fuer Bewerbungen.
Ich weis das es keine Abkuerzung gibt beim Thema lernen und stelle mich auch nicht dagegen und ich nutze meine zeit auch und baue einige sachen.

 

[lokked]

Um genauer auf deine erste Frage zu antworten: Benutzen kannst du eine SQL Datenbank auch ohne Joins etc., nur macht man das aus Effizenzgründen und zur Vermeidung von Fehlern, die zu unvollständigen oder nur teilweise richtigen Daten führen nicht. Also im professionellen Einsatz.
Nennt man referentielle Integrität, im Netz findest du sattsam Erklärungen/Videos dazu.

 

[wahli]

@lokked
Ich habe mal eine große Firmensoftware (ähnlich SAP) gesehen, die hat bewusst komplett auf foreign keys in der DB verzichtet, um maximale Performance zu haben. Die Abhängigkeiten wurden dann auf Softwareebene abgebildet und mit Transaktionen abgesichert.
Ich rate aber trotzdem dringend davon ab. Wenn da sich mal ein Fehler einschleicht, brennt die Hütte.

@BTCStorage
Wenn du nicht weißt, wofür du eine DB verwenden sollst (außer Konfigurationen und Einstellungen), ist dir nicht zu helfen. Denke dir eine sinnvolle Applikation aus, die eine Datenbank benötigt.
Beispiel "Webshop": es gibt beim Webshop so viele technische Herausforderungen, dass du dich damit sehr intensiv und lange beschäftigen kannst.

 

[LencoX2]

Full Stack heisst natürlich auch SQL.
Es mag Leute geben, die es als unnötig, veraltet etc ansehen.
Aus Erfahrung kann ich folgendes sagen:
RDBMS mit SQL als Abfragesprache sind aus Enterprise Grade Applikationen nicht wegzudenken. Daran wird sich nichts ändern in absehbarer Zeit.

Wer das nicht will/kann sollte sich auf Frontend oder andere Gebiete spezialisieren.

 

[[ChAoZ]]

18 Jahre Web Dev Erfahrung hier.

Es kann sein dass du OP nie SQL brauchen wirst weil die gesamte Datenbank Strukturen bereits vorliegen und du diese lediglich über APIs konsumierst. Verlass dich aber nicht drauf.

Als Dev solltest du MySQL durchaus beherrschen und seien wir mal ehrlich, so schwer ist das nicht. Wir reden hier nicht von Oracle (schwerer), MSSQL (auch einfach) oder Postgres (anspruchsvoller).

CRUD sollte man beherschen (google es wenn du den Begriff nicht kennst). Wenn du mit Stored Procedures und Joins umgehen kannst, bist du schon mehr besser als 50% aller WebDevs.

Mehr Wissen = mehr Aufgaben = mehr Verantwortung = mehr Gehalt.

 

[SheepShaver]

SQL ist heutzutage weit weniger wichtig als noch zu den 00er Jahren. Viele moderne Software-Architekturen setzen auf unstrukturierte Daten, die in Key-Value- und Document-Stores (MongoDB, CouchDB, Cassandra, etc.) abgelegt werden. Kommuniziert wird mit den Datenbanken über die SDKs.

 

[Tokolosh]

SQL ist heutzutage weit weniger wichtig als noch zu den 00er Jahren.

Sorry, was ist das denn bitte für ein Quatsch? Ich glaube du hast einfach keine Ahnung.

Das hat absolut nichts mit einem "modernen Softwarestack" zu tun. Du kannst nicht einfach NoSQL verwenden als Alternative. Das fliegt dir irgendwann komplett um die Ohren. Der Anwendungsfall ist sehr speziell und überhaupt nicht so weit verbreitet, wie es von den Tech-Youtubern beschrieben wird.

Willst du SQL tatsächlich als altbacken darstellen? Schau dich dochmal um, relationale Datenbanken sind überall vertreten, seit Jahrzenten.

 

[Raijin]

Worüber reden wir eigentlich? Die SQL-Basics mit ein paar Selects, Joins, Inserts, Updates, Deletes und dergleichen sind trivial und problemlos in 5 Tagen zu lernen. Damit erschlägt man gefühlt 90% aller Anwendungsfälle. Die restlichen 10% bestehen aus anspruchsvolleren Anweisungen oder gar dem Design einer komplexen Datenbank. Wenn man 90% kann, ist das schon die sprichwörtliche halbe Miete.
Es mag ja sein, dass der eine oder andere Job ohne SQL auskommt, aber dann kann man sich eben auch nur auf diese bewerben und bringt sich selbst um die Chance bei allen anderen Jobs.

Das ist wie Führerschein auf Automatik machen. Klar, kann man machen, aber wenn's dumm läuft, war's das dann auch mit dem (Schalt-)Mietwagen im Urlaub. "Tut mir leid, wir haben zur Zeit kein Fahrzeug mit Automatik da..."


*edit
Wer 90/10 unpassend findet, darf sich gerne ein anderes Verhältnis denken. Es geht ums Prinzip

 

[Drexel]

CRUD sollte man beherschen (google es wenn du den Begriff nicht kennst). Wenn du mit Stored Procedures und Joins umgehen kannst, bist du schon mehr besser als 50% aller WebDevs.

Mehr Wissen = mehr Aufgaben = mehr Verantwortung = mehr Gehalt.

Ja aber der Wille sich Neues anzueignen ist hier offensichtlich nicht vorhanden, er hätte die Chance gehabt sich kostenlos in was neues einführen zu lassen, wählt aber lieber den Weg des geringsten Widerstands....

 

[SheepShaver]

Sorry, was ist das denn bitte für ein Quatsch? Ich glaube du hast einfach keine Ahnung.

Right back at you.

Das hat absolut nichts mit einem "modernen Softwarestack" zu tun. Du kannst nicht einfach NoSQL verwenden als Alternative. Das fliegt dir irgendwann komplett um die Ohren. Der Anwendungsfall ist sehr speziell und überhaupt nicht so weit verbreitet, wie es von den Tech-Youtubern beschrieben wird.

Warum soll dir NoSQL um die Ohren fliegen? Unstrukturierte Daten haben fast nur Vorteile:

• leichte Anpassbarkeit an neue Anforderungen, da kein Schema
• Daten können im nativen Format bleiben (JSON, BLOB, plain text, völlig egal)
• Skalierbarkeit
• Performance
• kein Administrationsaufwand

In meinen Projekten der letzten 10 Jahre waren relationale Datenbanken nur eine Randerscheinung.

Willst du SQL tatsächlich als altbacken darstellen? Schau dich dochmal um, relationale Datenbanken sind überall vertreten, seit Jahrzenten.

Ja kenn ich. Ich habe vor 15 Jahren auch noch mit Microsoft SQL Server und Oracle rumhantiert. Was ich damit ausdrücken will ist, dass man heutzutage nicht automatisch bei jedem Softwareprojekt zu einer relationalen Datenbank greift, da viele Probleme sehr viel eleganter mit unstrukturierten Daten zu lösen sind.

 

[BeBur]

Ja aber der Wille sich Neues anzueignen ist hier offensichtlich nicht vorhanden, er hätte die Chance gehabt

Habe den starken Eindruck, dass TE sich gekränkt fühlt, dass er den SQL Kram nicht so gut verstanden hat, weil er eigentlich findet, dass der Kurs unter seiner Würde ist, da er schon was gemacht hat in Richtung programmieren.

 

[sh.]

SQL ist wie PHP und Java. Bei PHP und Java wird auch jedes Jahr gesagt keiner benutzt es und es lohnt sich nicht mehr sich damit zu befassen... das wird wahrscheinlich auch noch die nächsten 30 Jahre behauptet

 

[u-blog]

3 nasse Handtücher brauchen 3 Stunden zum Trocknen. Wie lange brauchen 9 nasse Handtücher zum Trocknen?

Stimmt halt absolut nicht, die Antwort ist recht plausibel:

The time it takes for towels to dry depends on various factors, including the thickness of the towels, the humidity in the room, and the airflow around the towels. However, if we assume that hanging up one towel takes 3 hours to dry, we can make a rough estimate for drying three towels.
If you hang up three towels side by side, they will likely take a bit longer to dry than a single towel because they may block some of the airflow to each other. Let's estimate that it might take approximately 4-5 hours for the three towels to dry together, assuming similar conditions for all three towels.
Again, please note that this is a rough estimate, and the actual drying time can vary based on the factors mentioned earlier. Thicker towels or higher humidity levels may prolong the drying time.

 

[Raijin]

Tja, so ist das eben bei diesen KIs. Ich hatte ChatGPT exakt dieses Frage direkt vor meinem Beitrag gestellt und ChatGPT antwortete genau so wie ich es geschrieben hatte, mit 9 Stunden. Gebe ich die Frage jetzt nochmal so ein, kommen in der Tat 3 Stunden raus.

Und genau das unterstreicht meine Aussage, dass man diesen wahrscheinlichkeitsbasieren Antwortautomaten nicht blind vertrauen kann, weil sie ihre Antworten nicht nach menschlichen Maßstäben geben. In diesem konkreten Fall könnte es beispielsweise sein, dass ChatGPT speziell auf diese Frage neu trainiert wurde, weil sie nicht von mir stammt, sondern aus einem sehr aktuellen Video eines bekannten KI-Wissenschaftlers, dessen Name mir gerade nicht mehr einfällt. Es ist davon auszugehen, dass viele, sehr viele Menschen diese Frage gestellt haben und man nun die Antwort angepasst hat.

Dasselbe gilt für Source-Code. Ja, ChatGPT kann lauffähigen Code produzieren, aber wiederholte Anfragen - ggfs mit minimal abweichender Fragestellung - können von jetzt auf gleich ein komplett anderes Ergebnis liefern.

 

[Bohnenhans]

Das ChatGPT Netz ist doch nicht wirklich dynamisch sondern statisch - die Gewichtung der Nodes wird doch nicht mehr angepasst - maximal im Laufzeit RAM.

Der Lernteil = "Gewicht" der Nodes ist eigentlich immer final - bis eben ein komplettes Neutraining durch OpenAI vorgenommen wird.

SQL ist sicher sinnvoll - weil sehr viel halt noch darauf basiert, auch wenn ich denke dass in Zukunft immer mehr Abtraktion einziehen wird. Ich bastle mir selbst für Hobbyprojekte lieber Klassen die sich per Reflection selber "irgendwie irgendwohin" speichern und ihre (Daten)Beziehung unabhängig der Speicherform dann selber aufbauen. Wle ich eben mit den Klassen/Daten arbeite wie ich sie für sinnvoll halte, und mir das möglichst "egal" ist wie die gespeichert werden - denn das kann sich doch immer ändern.

Wobei JOINs etc natürlich Super Basic sind xD die sind natürlich immer wichtig.

 

[u-blog]

dass man diesen wahrscheinlichkeitsbasieren Antwortautomaten nicht blind vertrauen kann

Da gehen wir d'accord.

 

[Bohnenhans]

Es ist ja nie verkehrt die Basics zu verstehen - auch wenn man sie vielleicht nicht wirklich braucht, dann verschiebt das Gehirn die Infos ja eh von alleine irgendwo nach hinten in den Schrank und man kann sie gegebenenfalls wieder einfacher herauskramen, falls man die doch irgendwann mal braucht.

 

[Madcat69]

Das sehe ich auch so - Basics sollte man in so einem Job drauf haben. Ich habe selbst auch keine klassische IT-Ausbildung, im Grunde alles selbst erarbeitet. Aber in den letzten 25 Jahren kam ich da beruflich mit Informix, Oracle und jetzt MS SQL Server in Berührung, privat mit mySQL. Und wenn man die Basics drauf hat, hilft einem das im Verständnis enorm.
Und je nachdem welche Aufgabe man hat ist mal eben eine etwas kompliziertere Abfrage, die ein fertiges Programm nicht unterstützt, in SQL schnell selbst gemacht.

 

[Bohnenhans]

oder evtl zum reparieren einer DB falls mehrere Programme zugreifen und eines Fehler verursacht hat ist das evtl auch sinnvoll.