Whiz-zarD

Wenn du aber in den Code verstehen möchtest, dann bleibt dir nichts übrig. Trau dich ruhig. Du bist ein Azubi und das wissen deine Kollegen auch. Daher werden sie dir wohl nicht den Hals umdrehen, wenn du Fragen stellst. Aller Anfang ist nun mal schwer. Auch für jemanden, der schon seit Jahren in diesem Beruf arbeitet und dann in einer neuen Firma anfängt. In der Firma, wo ich arbeite, bekommen neue Entwickler auch erstmal mehrere interne Schulungen, um die Software zu verstehen. Da geht es auch um technische Dinge, wie z.B. wie das intern entwickelte Framework funktioniert. Bei mir hat das auch ca. ein halbes Jahr gedauert, bis ich die Software weitestgehend durchdrungen habe. Außerdem hat dein Chef ja auch schon erkannt, dass du Defizite hast. Also weiß er auch, worauf er sich da einlässt. Wie gesagt, trau dich einfach, nachzufragen, wenn du nicht weiterkommst.

Es wird doch hier immer argumentiert, dass der Fachinformatiker ein halber Kaufmann wäre, weil er Kosten, Risiken, etc. abschätzen können muss aber genau das musst du in allen anderen Berufen auch und das würde ja bedeuten, dass jeder Beruf ein halber Kaufmann wäre und deshalb sage ich, dass der Fachinformatiker kein Kaufmann ist, da er auch nur über das selbe Grundwissen wie jeder andere verfügt. Ich denke, dass einigen hier die Weitsicht fehlt und nicht über ihren eigenen Tellerrand hinausschauen. Dann würden sie auch merken, dass ihr Wissen über BWL gar nicht so groß ist, wie sie wohl vermuten. Mag sein, dass im Ausbildungsrahmenplan drinnen steht, dass der Fachinformatiker über gewisse Kaufmännische Erfahrung besitzen muss aber ich kenne keine duale Ausbildung, wo in der Berufsschule nicht das BWL-Grundwissen beigebracht wird, denn wie gesagt, das benötigt jeder Beruf, denn überall geht es um die Wirtschaftlichkeit.

Das lernst du in jedem x-beliebigen Beruf auch... Das würde ja dann bedeuten, dass der Mechatroniker auch ein kaufmännischer Beruf wäre, denn er muss ja Ahnung von Lieferzeiten, Marktpreisen, Kostenschätzung und Risiken haben ... Das kannst du jetzt mit jedem Beruf fortfahren.

Ich habe Links rausgesucht. Selbst die offizielle Beschreibung zu diesem Beruf verrät nichts über kaufmännische Fähigkeiten ... Komischerweise ist das Forum die einzige Quelle, die ich finde, wo dies wie ein Berseker behauptet wird, ohne offiziellen Quellen zu nennen. Wenn das nur darauf hinausläuft, dass man irgendwelche Kosten zusammenrechnen muss, dann ist jeder Beruf ein kaufmännischer Beruf ... Ja und? Ich habe damals als Mechatroniker als Zeitarbeiter gearbeitet und musste auch Angebote einholen, Preise vergleichen und musste Aufwände einschätzen. Ist der Mechatroniker nun plötzlich auch ein kaufmännischer Beruf? Das gehört nun mal zu einem Job dazu.

Eine tolle Antwort. Im Klartext: Dir fehlen die Argumente ...

Dann zeige mir doch mal, wo es steht ... Nirgends steht das. Selbst nicht mal Fachinformatiker, die schon seit über 10 Jahren in diesem Beruf arbeiten, die ich kenne, sehen es so ...

Selbst die Arbeitsagentur erwähnt beim Fachinformatiker nicht, dass er kaufmännische Fähigkeiten benötigt. Wie gesagt, dafür gibt es den Informatikkaufmann: https://berufenet.arbeitsagentur.de/berufenet/faces/index?path=null/kurzbeschreibung&dkz=7795 https://berufenet.arbeitsagentur.de/berufenet/faces/index?path=null/kurzbeschreibung&dkz=7856 https://berufenet.arbeitsagentur.de/berufenet/faces/index?path=null/kurzbeschreibung&dkz=7847 Auch die Unicum-Unternehmensgruppe weist daraufhin, dass es nicht nur den technischen Fachinformatiker gibt, sondern auch den Informatikkaufman: http://karriere.unicum.de/berufsorientierung/berufsbilder/ausbildung-der-it-branche Ich habe damals die Zeit miterlebt, als diese Berufe entstanden, weil das damals die Zeit war, wo ich mich auf einen Ausbildungsplatz beworben habe und niemand hat damals den Fachinformatiker als einen teils kaufmännischen Beruf angesehen, sondern immer als einen technischen Beruf.

Er ist im dritten Lehrjahr. Also fast ausgebildet. Da sollte man schon die Basics kennen.

Das ist schlichtweg falsch. In jedem Beruf lernt man etwas über BWL. Das habe ich damals in meiner Mechatroniker-Ausbildung und in meiner Ausbildung als Informatik-Assistent auch getan. Also stell es bitte nicht so hin, als sei der Fachinformatiker ein halber Kaufmann, denn das stimmt einfach nicht! Der Fachinformatiker wurde als praktizierender Facharbeiter ins Leben gerufen und zwar zur Anfangszeit der damaligen Dotcom-Blase (1997), als solche Facharbeiter noch rar waren. Der Fachinformatiker sollte genau den Missstand, dass eben viele Entwickler eigentlich nur Informatikkaufmänner waren, beheben. 1997 hatte man mehrere IT-Berufsfelder gebildet, die da waren: Fachinformatiker, Informatikkaufmann, IT-Systemkaufmann und IT-Systemelektroniker. Also Techniker und Kaufmänner hatte man von Anfang an getrennt.

Du solltest erst mal ehrlich zu dir selbst sein und dich wirklich fragen, ob der Beruf etwas für dich ist. Daheim hobbymäßig etwas vor sich hinwerkelt ist was anderes, als dies hauptberuflich zu tun. Ich spreche da aus Erfahrung, da ich schon eine Depression aus diesen Gründen hinter mir habe. Was hättest du denn erwartet? Ich habe bis jetzt noch keine Softwarefirma gesehen, die wie im Bilderbuch ihre Software pflegte. Ich habe bis jetzt noch keine Firma gesehen, die ihren Code kommentierte und dokumentierte. Überall hieß es: "Der Code sei historisch gewachsen." Also mit anderen Worten: Uns war es wichtiger, dass der Code schnell zurecht gefrickelt wird. Sowas wirst du immer wieder erleben aber warum ein großes Projekt mit vielen Klassen schlecht sein soll, ist mir irgendwie nicht so klar und wieso man nach technischen Problem nicht suchen kann, ist mir auch nicht klar. Sicherlich, Google wird dir kaum sagen, wie man z.B. einen Zins- und Tilgungsplan implementiert (wie in meinem Fall) aber vielleicht sind deine Arbeitspakete noch zu groß, um gezielt nach Antworten suchen zu können. Das ist vielleicht wie bei der Antwort der Frage "nach dem Leben, dem Universum und dem ganzen Rest". Das soll jetzt nicht heißen, dass es überhaupt keine Firmen gibt, die ihren Code sauber halten aber ich habe die Erfahrung gemacht, dass dies doch eher Ausnahmen sind und wie gesagt, bis jetzt habe ich noch keine Firma gesehen, die das gemacht hat und ich habe inzwischen einige Firmen sehen dürfen. Von Startup-Firmen bis hin zu Firmen, die schon seit 20 Jahren Software entwickeln. Mag ja alles sein, dass deine jetzige Firma nicht ganz so rosig ist aber wenn ich lese, dass du doch schnell das Handtuch wirfst, wenn es Probleme gibt, habe ich doch so meine Zweifel, dass der Beruf was für dich ist. Jeder hat mal Hochs- und Tiefs aber ich habe das Gefühl, dass du die Probleme eher in der Firma suchst, anstatt bei dir selbst. Vielleicht sehe ich es auch falsch aber so kommt es mir derzeit rüber.

Als Text soll ein &-Zeichen vorkommen? Dann muss der Text mit als CDATA-Abschnitt definiert werden. Beispiel: <Tag><![CDATA[Clever & Smart]]></Tag> Oder man nimmt gleich ein Framework, was eine XML-Datei generieren kann und spart sich die Mühe, dies selbst zu implementieren.

Was genau soll denn gespeichert werden? Was soll denn in HEX umgewandelt werden? Für mich ist nicht ganz klar, was du eigentlich erreichen möchtest. Darüber hinaus sieht die Zeile var cols = rows; nicht richtig aus. Das müsste wohl var cols = rows[i]; heißen. Ich bin zwar kein JavaScript-Experte aber in JavaScript gibt es doch mit Sicherheit eine Foreach-Schleife. Dann brauchst du auch nicht mit den ganzen indexierten Kram rumhantieren. Außerdem ist mir nicht klar, was die Variablen: var cardID = rows[0]["ID"]; var name = rows[1]["Name"]; var accountnumber = rows[2]["Accountnumber"]; var amount = rows[3]["Amount"]; var datum = rows[4]["CreateDate"]; var transaktionsID = rows[5]["TransactionID"]; var ort = rows[6]["Location"]; bringen sollen. Du gehst die Tabelle nun quasi Diagonal durch und wenn du weniger als sechs Zeilen hast, erhält du eine "Array Out of Bounds"-Exception.

Warum eine Codegenerierung? Verstoßen die generierten Klassen gegen das DRY (Don't Repeat yourself)-Prinzip? Wenn Ja, wieso nicht die Vermeidung von Code-Doubletten durch Vererbung und Generics?

Ich kann es mir nur so vorstellen, dass du die Bits nun zeichnerisch darstellen sollst. Die 25 Bits entsprechen ja die 25 dpi. dpi steht ja für "Dots per Inch" und wird häufig als Synonym für ppi "Pixel per Inch" genommen.

Wenn das für DICH wichtig ist, dann komme aber nicht mit solchen Sprüchen: Ob der Join sinnvoll ist, oder nicht lässt sich auch mit der Aufgabenstellung nicht eindeutig sagen. Es kommt dann auf die eigenen Präferenzen an. Entweder man macht hier ein Join und definiert eine Gruppierung, weil im Select Aggregatsfunktionen aufgerufen worden sind oder man erstellt im Select Subselects. Die Join-Variante hat nun das Problem, dass wenn weitere Spalten im Select ausgewiesen werden sollen, müssen diese Spalten auch noch zusätzlich in die Gruppierung eingepflegt werden. Man hat also einen doppelten Pflegeaufwand. Bei den Subselects kann man einfach weitere Spalten hinzufügen. Darüber kann man sich gerne unterhalten. Alles andere hat hier aber nichts zu suchen.

Die Anforderungen waren doch klar ... Er hat die offizielle Lösung gleich mitgeliefert. Es ging doch nur darum, um zu schauen, ob seine Lösung das gleiche macht, wie die offizielle Lösung. Wozu man dann noch tausend Mal nach der Aufgabe fragen muss und wieso man mit "Ein Where ist ein Join" kommt, ist mir ein Rätsel, denn das war gar nicht das Problem ... Die Offizielle Lösung war jetzt auch nicht so schwer zu verstehen, sodass man als Anhaltspunkt noch die Aufgabe hätte benötigen müssen. Also komm mal wieder auf den Teppich ...

Wenn man mal den ganzen Bullshit löschen wurde, der von den anderen geschrieben wurde, würde man erkennen, dass ich der einzige war, der ihm bei seinen Fragen tatsächlich geholfen hat ...

Nein, ich bin hier so ziemlich der einzige, der tatsächlich auf die Fragen vom Threadersteller eingegangen ist ich versuche auch die gefährlichen Aussagen einiger Nutzer zu korrigieren. Ich habe auch nicht mit der Where- und Join-Geschichte angefangen. Eine Where-Klausel ist nun mal kein Join. Ein impliziter Join ist IMMER nur ein Cross Join und nichts anderes. Was man hinterher in der Where-Klausel filtert, ist eine andere Geschichte. Das Ergebnis ist vielleicht das selbe aber semantisch macht es einen gravierenden Unterschied und auch intern passieren unterschiedliche Dinge. Ein Optimizer versucht daher immer einen impliziten Join in einen expliziten Join zu überführen, weil dadurch die Strategie günstiger wird. So etwas sollte man im Hinterkopf haben, um das Statement schon optimal zu schreiben, weil das Parsen, Optimieren und Erstellung des Explain-Plans auch viel Zeit benötigt. Nicht umsonst finden intern weitere Caching-Strategien statt, die die SQL-Statements und deren Explain-Plan cached. Dabei werden dann Konstanten gegen Platzhalter ausgetauscht, damit der selbe Explain-Plan mit unterschiedlichen Konfigurationen ausgeführt werden kann. Das Problem war aber hier gar nicht der Join, sondern die fehlende Gruppierung ... Wieso man hier überhaupt auf den Join gekommen ist, ist mir weiterhin schleierhaft.

Und deshalb sollte die Lösung auch richtig sein, was sie hier aber nicht ist und ich kann mir schon vorstellen, dass es für einige Prüflinge Nachteile bei der Bewertung geben wird, wenn der Prüfer sich zu sehr an der falschen Lösung orientiert. Es ist schon ein Armutszeugnis, dass die IHK es immer noch nicht schafft, fehlerfreie Prüfungen zu schreiben. Selbst zu meiner Zeit, was inzwischen schon gute 15 Jahre her ist, gab's zur Abschlussprüfung mehrere Bögen mit Korrekturen, die es nicht in den Druck geschafft haben und selbst die Korrekturen waren noch teilweise falsch ... Der Klassiker war, dass man eine Reichsnadel zur Zwischenprüfung mitbringen sollte. Gemeint war aber eine Reißnadel ...

Der Join passiert aber implizit in der FROM-Klausel und nicht in der WHERE-Klausel...

Das erste ist ein sog. implizierter Join, der so nicht mehr verwendet werden sollte, da man hier ein kartesisches produkt erzeugt, welches man dann filtert. Das ist sehr langsam und sehr speicherintensiv. Explizite Joins hingegen arbeiten direkt mit den Indizes (z.B. mit dem hash Join Algorithmus) und sind somit deutlich schneller und verbrauchen auch weniger Speicher. Ein optimizer würde daher versuchen implizite joins in explizite umzuwandeln. Ein implizierter Join kann also nur ein cross Join abbilden. Für alle anderen Arten von Joins werden unterschiedliche Algorithmen verwendet. Das Resultat mag vielleicht das selbe sein. Die Ausführung aber eine völlig andere.

Ja, sicherlich, aber wenn man bei einem DBMS den Explain-Plan aufruft, hat man schon ein sehr gutes Indiz dafür, wie die anderen das in etwa machen. ähm, nein ... O_o Mit JOIN verbindet man zwei Tabellen zu einer Ergebnismenge und mit WHERE filtert man ... Wie willst du denn ein JOIN mit einer WHERE-Klausel abbilden?

Leider ist das überhaupt keine Lösung, Da muss ich @Sawfare recht geben. Ich hatte mich auch gefragt, was nun "ausgaben" sein soll? Da haben sie sich wohl verschrieben, denn im Pseudocode ist von "einkommen_miete" die Rede, was plötzlich da ist. Dann darf die For-Schleife auch nicht über "AnzahlGruppe" gehen und dann indexiert auf die Mieter-Daten zugreifen. Wenn du mehr Gruppen hast, als Daten, dann fliegt dir die Anwendung um die Ohren und wenn du mehr Mieter-Daten hast, wird er nicht alle berücksichtigen. Die Lösung geht also davon aus, dass man exakt die selbe Anzahl an Gruppen und Mieter-Daten hat. Darüber hinaus ist das ein extrem schlechter Programmierstil, was die IHK hier vom Vorschein gibt und wer später so entwickelt, der gehört erschlagen. Indexiert auf Mehrdimensionale Arrays zugreifen ohne die Semantik zu kennen ist so 80er und selbst unter C würde man dafür Structs verwenden. Das ist echt schon peinlich, was die IHK dort produziert ...

So, du müsstest dein Statement folgendermaßen ändern: SELECT a.Art_Id, a.Art_Nummer, a.Art_Bezeichnung, a.Art_Preis, SUM(r.RgPos_Menge) As MengeGesamt, COUNT(r.RgPos_Id) As Anzahl FROM Artikel a INNER JOIN RechnungsPosition r ON a.Art_Id = r.RgPos_ArtId GROUP BY a.Art_Id, a.Art_Nummer, a.Art_Bezeichnung, a.Art_Preis ; Der Grund für die Änderungen ist, dass Aggregationsfunktionen, wie z.B. COUNT, SUM, MIN, MAX, AVG nur auf Gruppierungen angewendet werden können. D.h. wir müssen Gruppen bilden. Wir bilden die Gruppen über Art_Id, Art_Nummer, Art_Bezeichnung und Art_Preis. Mit dieser Lösung haben wir aber das Problem, wenn wir eine weitere Spalte ausgeben wollen, müssen wir die Spalte auch in die Gruppierung einbeziehen. Man muss das Statement also an zwei Stellen anpassen und das finde ich persönlich nicht so toll. Man müsste sich aber mal den Explain-Plan anschauen, welche Lösung performanter ist. Das weiß ich gar nicht so richtig.

Darauf habe ich geantwortet : Weil dies mit ANSI SQL der beste Weg ist. Einige DBMS haben noch analytische Funktionen, mit denen man das auch noch hinbekommen kann aber die zählen wohl in der Prüfung nicht. Man könnte es auch mit ANSI SQL so hingekommen, wie du denkst, aber das wäre eher ein workaround und nicht mehr wirklich semantisch lesbar, weil man einige Annahmen treffen müsste. Die Lösung schreibe ich später noch hier rein. Ich bin gerade mit einem Smartphone unterwegs und mit code-editierungen hat mein Smartphone so einige Probleme.