Finux

Also bei deiner Lösung fehlt schon mal die MaschineID das würde denke mal Punktabzug geben und warum DATE(Today-4)? Es gibt ja extra die spalte Datum bei Laufzeit.
Ansonsten fehlt von der "Lösung" die Summe der Laufzeit, wobei ich mich hier noch immer frage es steht nirgends beschrieben, wie die Laufzeit abgespeichert wird. Es kann ja auch sein das es so ist wie wir es uns denken in Laufzeit wird immer der Aktuelle Wert abgespeichert oder man muss es wirklich zusammenrechen. Dies ist in der Aufgabe aber nicht richtig Definiert.

Also Die Laufzeit hat ein Datum mit im Table. Es wird also immer die Stunden gespeichert die die Maschine an einem bestimmten Tag gelaufen ist, ansonsten macht das Feld keinen sinn und es wäre keine 3 Normalform.
 
und zu 
Ein JOIN ist das gleiche wie ein INNER JOIN.

Die Lösung ist (bis auf das ich das INNER bei den Joins weggelassen hab) so von der IHK vorgegeben.

Hier die Lösung:

b)
SELECT K.KundeID, K.KundeFirma, K.KundeAdresse, M.MaschineID,     (SELECT SUM(L.Stunden) FROM Laufzeit AS L        WHERE L.MaschineID = M.MaschineID AND L.Datum > M.DatumLetzteWartung) AS Laufzeit FROM Kunde AS K     INNER JOIN Maschine AS M ON K.KundeID = M.KundeID         INNER JOIN MaschineTyp AS MT ON M.MaschineTypID = MT.MaschineTypID             WHERE (SELECT SUM(L.Stunden) FROM Laufzeit AS L                     WHERE L.MaschineID = M.MaschineID                     AND L.Datum > M.DatumLetzteWartung) + 100 > MT.WartungsintervallInStunden;  

Mit zunehmender Erfahrung bekommt man ein Gefühl dafür, wann eine generische Lösung vom Vorteil  ist, oder nicht. Ich würde aber immer erst mit einer konkreten Lösung für ein Problem anfangen und erst, wenn man merkt, dass dass man die Lösung für ein ähnliches Problem benötigt, dann sollte man über eine generische Lösung nachdenken.
Zur Aufgabe:
Denke in kleinen Schritten. Mache dir über Performance erstmal überhaupt keine Gedanken. Viel wichtiger ist es, eine Lösung zu finden, die auch les- und wartbar ist. Erst, wenn man merkt, dass die Performance ein Problem wird, sollte man sich darum kümmern. Die Performance könnte ja evtl. gar kein Problem sein. Da macht es wenig sinn, im Vorfeld sich darüber den Kopf zu zerbrechen und eine Lösung ausdenken, die zwar vielleicht performant ist, aber keiner versteht.

Moin,
du solltest die Fragen in verschiedenen Themen unterbringen, die haben ja nichts miteinander zu tun.
Man muss es eben immer im Rahmen halten, ich finde es auch schwer dort eine Daumenregel zu finden.
Wenn deine Web-Anwendung per Formular eine Excel-Datei mit Fahrzeugteilen importieren können soll, macht es Sinn die Komponenten so zu gestalten, dass man auch Komponenten für andere Dateiformate implementieren kann, z.B. wäre der Wechsel auf csv ja nicht sonderlich überraschend.
Genauso wie man die Formate recht einfach austauschbar machen kann, kann man auch die Übertragungsarten abstrahieren; es muss die lesende Komponente ja nicht interessieren ob die Datei jetzt per HTML-Formular von der Website hochgeladen oder per SOAP-WebService gesendet wurde also koppelt man vielleicht nicht die Request-Objekte aus dem Framework an die Services sondern bereit die Daten vorher auf und gibt sie dann weiter...
 
 
Aber manchmal gibt es eben Stellen wo es heißt: "Das hier ist das Format für Buchungen das sich frühestens in 40 Jahren ändert.", da lohnt es sich dann eher nicht nochmal 2 Tage* zu investieren um generischer unterwegs zu sein.
 
* oder 2 Stunden, in manchen Situationen ist die generische Lösung einfach irrelevant

Ich habe das bisher immer nur in dem Zusammenhang gehört: Entweder, dass ein Algo nicht ein spezifisches Problem löst, sondern ein Recht allgemeines Problem. Sprich recht wiederverwendbar für verschiedene Situationen. Das könnten z.B. Extention Methods (für die C#ler hier) sein (wer eine Extention Method für DateTimes schreibt, der muss sie so schreiben, dass sie für alle DateTimes anwendbar ist). 
Das kommt auf das Ausmaß an. Wenn es wesentlich Mehrarbeit erfordert, dann evtl. mit den Vorgesetzten sprechen. Oft wird meist einfach gerne nur das gemacht, was auch mit dem Kunden abgesprochen wurde. Wenn dies später Probleme macht, tja dann muss der Kunde halt noch eine Lösung *nachbestellen*. Als Entwickler natürlich unschön, wird aber oft bewusst gemacht.
In Sachen IHK: Halte dich an die Arbeitsanweisungen...wenn diese nicht spezifisch sind, kannst du oft machen, was du willst, Hauptsache es ist am Ende richtig. Am Ende heißt das meist: mach was am effizientesten für deine begrenzte Bearbeitungszeit ist.
Bei deiner Aufgabe z.B. finde ich den Ansatz deines Ausbilders auch besser, da man in diesem Algo später eine vordefinierte Liste übergeben könnte, welche auf verschiedene Art bearbeitet (das wird dann halt mithilfe der Parameter entschieden) wird. Du willst eine Liste generieren, vergisst aber, dass diese schon existieren könnte. Du müsstest für diesen Fall also sowieso einen Algo schreiben, der eine existierende Liste entsprechend bearbeitet.

Was genau verstehst du unter Allgemeingültigkeit? Grundsätzlich sollte ein Progeamm das leisten, was die Spezifikation verlangt und auch wenn Programmierer oft eine Tendenz dazu haben alles möglichst generisch machen zu wollen, ist es oft keine gute Idee.
Was genau ist denn deine Frage im zweiten Teil? Dein Ansatz ist in der Tat effizienter, der deines Ausbilders dagegen einfacher umzusetzen. Das ist eine Abwägung, die man tatsächlich sehr oft machen muss. Gerade als Anfänger empfiehlt es sich natürlich erst mal die einfachste Lösungsmöglichkeit zu verfolgen und dann erst später ggf. zu optimieren.

% ist der Modulo-Operator, der führt eine Division durch und gibt den Rest als Ergebnis zurück
// ist der abrundende Divisionsoperator
[edit]
Im Endeffekt macht n % 10 + sum_func(n//10) also nichts anderes als die letzte Stelle im Speicher zu halten und sum_func mit den vorhergehenden Stellen aufzurufen, anschließend wird die erste Stelle dann mit dem Ergebnis vom sum_func-Aufruf addiert.
  [/edit]
 
Mir fehlt gerade die Fantasie für eine bessere Darstellung deshalb...
Der rekursive Ablauf würde so aussehen:
Aufruf sum_func(4321)
Zeichnlänge größer 1 Skip If-Block return 4321 % 10 [= 1] + Aufruf sum_func(4321 // 10 [432]) Zeichenlänge größer als 1 Skip If-Block return 432 % 10 [= 2] +  Aufruf sum_func(432 // 10 [43]) Zeichenlänger größer als 1 Skip If-Block return 43 % 10 [= 3] +  Aufruf sum_func(43 // 10 [4]) Zeichenlänge ist 1 return 4 Das ist der Stack, der dann im Endeffekt so abgearbeitet wird
 
sum_func(4) return 4 sum_func(43) return 3 + 4 sum_func(432) return 2 + 7 sum_func(4321) return 1 + 9  

Hallo, 
bin gerade dann letztlich doch selbst auf eine Lösung gekommen, aber wer schon dabei geschaut und eine schöne Lösung gefunden hat- ich bin neugierig- postet sie mir bitte hier rein! 

Meine finale Lösung:
# --------------------------------------- Höchste Summer einer Teilfolge von Liste mit Integer --------------------- # """ Aufgabe 4: b) Gegeben sei eine Folge von n ganzen Zahlen in einem Array. Gesucht ist die maximale Summe aller Elemente in einer Teilfolge aufeinanderfolgender Zahlen. Die Eingangsfolge 12 -34 56 -5 -6 78 liefert bspw. die Summe 56 -5 -6 +78 = 123. """ # --------------------------------------- Funktion ----------------------------------------------------------------- # def save_to_dict(k, v): dict_of_num[k] = v def sum_list(num_list): pieces_add1 = num_list[:-1] pieces_add2 = num_list[1:] if len(num_list) > 2: if pieces_add1 not in dict_of_num.values(): add1 = sum(num_list[:-1]) print(add1, pieces_add1, "wurde berechnet!") save_to_dict(add1, pieces_add1) sum_list(num_list[:-1]) if pieces_add2 not in dict_of_num.values(): add2 = sum(num_list[1:]) print(add2, pieces_add2, "wurde berechnet!") save_to_dict(add2, pieces_add2) sum_list(num_list[1:]) else: print("Alrdy in dict!", pieces_add1, pieces_add2) else: print("rdy") # --------------------------------------- Programmstart ------------------------------------------------------------ # dict_of_num = {} num_list = [12, -34, 56, -5, -6, 78] #num_list = [4, 4, 4, 12] # Testliste für Trigger doppelter Berechnung! sum_list(num_list) for result in dict_of_num.keys(): print("DICT", result) #ToDo: Vermeide redundante Berechnungen! (Unterschiedliche Teilfolgen mit gleichem Ergebnis müssen zugelassen sein!) // Kein return, Kein string