Whiz-zarD

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:

Am 22.11.2016 um 10:21 schrieb neinal:

Ohne Aufgabenstellung wird dir auch niemand sagen können, ob du die volle Punktzahl bekommst.

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 ...

vor 15 Minuten schrieb neinal:

Du hast auf die Frage geantwortet. Ja. Aber geholfen hast du damit nicht.

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 ... 

vor 33 Minuten schrieb Chiyoko:

Natürlich hast du mit deinen Anmerkungen per se Recht, aber ein Azubi (noch dazu kurz vor der Prüfung) verwirrt und verunsichert alle Zusatzinformationen, die (für die IHK-Prüfung) nicht relevant sind. Eventuell ist hier "weniger mehr". Ohne dich jetzt angreifen zu wollen, ahbe ich persönlich das Gefühl, du willst dich mehr als "Spitzen-Entwickler" profilieren, als hier tatsächlich sinnvoll zu helfen. (Nicht böse gemeint!)

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.

vor 48 Minuten schrieb Chiyoko:

Prinzipiell würde ich sogar sagen (in dem hier beschriebenem Fall), dass der JOIN die vollen Punkte einbringt, da viele Prüfer (Achtung: persönliche Einschätzung, keine Fakten!) diese wohl als geläufiger ansehen bzw. ihnen besser bekannt sind.

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.

vor 59 Minuten schrieb Asura:

Eine Art Richtlinie an die sich Prüfer halten können, aber nicht müssen.

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. 

vor 37 Minuten schrieb Rienne:

Ist das nicht auch immer eine Frage des DBMS? Denn viele DBMS optimieren ja intern noch die Abfragen.

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.

vor 37 Minuten schrieb Rienne:

DENN: letzten Endes kann man jedes JOIN auch mit WHERE darstellen. Ob und in wiefern welche Lösung performanter ist, ist auch wieder eine Frage des DBMS.

ä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?

vor 13 Minuten schrieb Gottlike:

Ich habe mich auch schon über einige Empfehlungen der IHK geärgert, ändern wird das nichts.
Das Ziel ist aber auch nicht, exakt die Lösung wie die beschrieben hinzubekommen, sondern eine Lösung zum Problem zu finden. Wenn du es auf eine andere, aber ebenso korrekte, Weise löst, gibt es keine Probleme.

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.

vor 26 Minuten schrieb Sawfare:

Danke für deine Beteiligung am Thread, meine erste Frage auf deinen Post hast du allerdings noch nicht beantwortet:

 

Was wäre, wenn ich "Group by a.Art_Id" drann hänge?

Darauf habe ich geantwortet :

vor 6 Stunden schrieb Whiz-zarD:

Wird dann auch nicht funktionieren, da 

a.Art_Nummer, 
a.Art_Bezeichnung, 
a.Art_Preis,

nicht gruppiert sind oder du die Werte nicht mit SUM, COUNT, etc. aggregierst.

vor 27 Minuten schrieb Sawfare:

-> Falls du der Meinung bist, dass es ein Sub-Select sein MUSS, woher weiß ich das? 

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. 

vor 7 Minuten schrieb Asura:

Wir sind in einem Forum und er fragt um Hilfe. Ein einfaches "nein, bekommst du nicht. Das ist nicht mal Ausführbar", ist zwar die Antwort auf die Frage.. Aber keine Antwort die ihm hilft.

Bis jetzt hat er noch um keine Hilfe gefragt. Die Frage lautete, ob er die volle Punktzahl bekommt. Mehr nicht und die Antwort ist Nein, aus besagten Gründen. Alles andere kann man immer noch schauen. Das muss aber vom Threadersteller selbst kommen. Der Threadersteller hat davon nichts, wenn man ihn erst mal bis zur Unterhosengröße ausquetscht und dann Informationen bekommt, nach denen er gar nicht gefragt hat.

Du redest aber an der Aufgabe völlig vorbei. Das Where befindet sich in einem Subselect. Das hat nichts mit einem Join zu tun. Pro Ergebniszeile werden die Subselects aufgerufen und als Filter-Kriterium wird der Wert Art_Id aus der Ergebniszeile genommen.

Falls du es auch nicht so ganz mitbekommen haben solltest: Das obere Statement ist die offizielle Lösung und das untere Statement ist von @Sawfare. In der offiziellen Lösung gibt es also kein Join.

vor 7 Minuten schrieb Fauch:

In beiden Fällen wird das kartesische Produkt gebildet. Ob da WHERE oder JOIN steht ist zunächst einmal eine reine Frage der Syntax.

Wo siehst du ein Where?
Das einzige Where, was ich sehe, steckt im Subselect. Das ist aber kein Join...

Das war auch nicht die Frage. Sondern, ob er alle Punkte bekommen würde.

Und selbst dafür braucht man die Aufgabe nicht ...
Wie gesagt, interessant wird es erst, wenn das Statement auch ausführbar wäre. Ist es aber nicht. Folglich bekommt er nicht die volle Punktzahl. Frage beantwortet.

vor 4 Minuten schrieb Asura:

Und Whiz-zarD, in der Aufgabenstellung kann immer noch etwas stehen, was er hier nicht angibt. Wir sollten alle Wissen, dass die schriftliche AP oftmals alles andere als sauber und einfach gestellt ist.

Ja, schon klar aber wie gesagt, das SQL-Statement ist nicht mal ausführbar. Da braucht man die Aufgabe nicht, um das zu erkennen. Interessant wird es erst, wenn das Statement ausführbar wäre. Außerdem kennt er die Lösung. Da braucht man ihn nun auch nicht eine Lösung vorschlagen.

vor 53 Minuten schrieb Fauch:

Die "Where"-Bedingung ist in dem Fall auch ein JOIN, der wird zwar intern anders gebildet, bleibt aber ein JOIN.

Den Satz verstehe ich nicht mal. Eine Where-Klausel ist kein Join. Die Where-Klausel wird in einem Subselect verwendet.

Und die Antwort lautet nein, weil das SQL-Statement nicht mal ausführbar ist.

vor 4 Minuten schrieb neinal:

Danke. Bringt mich aber auch nicht weiter.

Weil ich nicht weiß was wo wie in deiner Datenbank steht.

Das ist so, als würde ich dir sagen, geh mir mal bitte ein Auto kaufen. Und wenn du fragst welches, sage ich dir "ein blaues"...^^

Viel braucht man doch gar nicht verstehen.
Das sind halt zwei Tabellen: Artikel und Rechnungsposition und die Tabelle Rechnungsposition ist mit der Tabelle Artikel über die Spalte Art_Id verknüpft. Mehr muss man doch nicht wissen.

vor 3 Minuten schrieb Sawfare:

und wenn ich ein "Group By a.Art_Id" drann hänge?

Wird dann auch nicht funktionieren, da 

a.Art_Nummer, 
a.Art_Bezeichnung, 
a.Art_Preis,

nicht gruppiert sind oder du die Werte nicht mit SUM, COUNT, etc. aggregierst.

Deine Lösung funktioniert nicht, da du kein GROUP BY angegeben hast. SUM und COUNT können nur auf Gruppen ausgeführt werden. Darum wurde in der oberen Lösung jeweils ein Subselect genommen.

vor 16 Minuten schrieb Albi:

aber man kann auch viel lernen und es wird später auch als FISI oder FIAE durchaus wichtig, wenn du mal deinem Vorgesetzten z.b. eine neue Soft- oder Hardware für euer Team oder das ganzes Unternehmen vorschlagen willst, kannst du fast sicher sein, das der dann von dir auch wissen will, was das kostet, ob es wirtschaftlich rentabel ist usw. da können dir diese "Grundkenntnisse" in BWL schon wirklich helfen.

Da reicht auch oft der gesunde Menschenverstand. Das ist eine Sache zwischen Kosten- und Nutzen. Kostet eine Software viel aber ist der Nutzen gering, dann rentiert es sich nicht. Solche Aussagen kann man auch ohne BWL-Kenntnisse aufstellen.

vor einer Stunde schrieb Crash2001:

1. Es ist afaik Teil JEDER Ausbildung (IHK und Handwerkskammer), damit die Grundlagen dazu vorhanden sind.

Eben.
Darum würde ich es auch gar nicht so groß an die Glocke hängen, wie es hier einige tun.
Man lernt vielleicht ein bisschen, was der Unterschied zwischen Haben und Soll ist und wie man eine Gewinn- und Verlustrechnung aufstellt aber das ist mehr im Stil eines kleinen Crashkurses und ist nur ein Bruchteil davon, was ein Kaufmann lernt. Dies an die große Glocke zu hängen, weil der Fachinformatiker seinen Ursprung beim Datenverarbeitungskaufmann hat, ist aus meiner Sicht ein wenig hochtrabend. Im Alltag wird man auch nicht viel damit in Kontakt kommen. Für eine Kostenaufstellung reicht auch der gesunde Menschenverstand. Außerdem wurde der Beruf Datenverarbeitungskaufmann 1997 in mehrere Berufe unterteilt. Es standen die Berufe Informatikkaufmann, IT-Systemkaufmann, Fachinformatiker und IT-Systemelektroniker. Der Fachinformatiker war also nicht als Kaufmann gedacht, sondern als praktizierender Facharbeiter. Vermutlich sind aber hier wohl einige zu jung und haben die damalige Dotcom-Blase nicht mitbekommen. Die neuen Berufe wurden nämlich damals zur Anfangszeit der Boom-Phase ins Leben gerufen.

vor 54 Minuten schrieb stefan.macke:

Nein.

A LEFT OUTER JOIN B -> alle Sätze aus A und verknüpfte Sätze aus B, falls vorhanden. Falls kein passender Satz in B vorhanden ist, werden NULL-Werte für die Spalten geliefert.

A RIGHT OUTER JOIN B -> alle Sätze aus B und verknüpfte Sätze aus A, falls vorhanden, ansonsten NULL-Werte.

Er fragte aber ob, A LEFT OUTER JOIN B nicht das selbe ist, wie B RIGHT OUTER JOIN A und ja, das ist das selbe. In beiden Fällen ist die Grundmenge A. Darum versuche ich immer als erstes die Grundmenge zu schreiben, bevor ich die Menge mit einem LEFT OUTER JOIN filtere. Das lässt sich semantisch besser lesen.

Aber die Frage, ob LEFT OUTER JOIN nicht das selbe ist, wie RIGHT OUTER JOIN muss mit einem Nein beantwortet werden. Es kommt hier auf die Reihenfolge an, wie die Mengen zueinander stehen.