supermari0

1.) Korrekt 2.) Zumindest langsamer, ob ein Endandwender da irgendeinen unterschied spürt wage ich aber zu bezweifeln (Mit Java kann man mehr als diese hässlichen langsamen Browser Applets machen , z.B. Azureus!) 3.) (T-)SQL ist eine Datenbank Programmiersprache! Und wenn man mit riesigen Datenmengen arbeitet kommt man um irgendeine Form von SQL in der Praxis kaum noch rum. 4.) Für dich? 5.) Um 7 der 8 Kriterien gings aber in der Aufgabe nunmal nicht und was die kurzen Antwortzeiten betrifft sind C++ und/oder SQL wohl doch eher die favoriten. Die Aufgabe ist einfach total Praxisfremd. In der Praxis würde so ein Programm in den meisten Fällen in C++/C#.NET/Visual Basic.NET unter Zuhilfenahme von SQL erstellt.

ich sollte noch anmerken das es sich bei dem codebespiel oben um T-SQL handelt. Aber solche Extensions die den SQL Standard um Kontrollstrukturen/Variablen erweitern gibts für jedes relevante DBMS (MSSQL: T-SQL, Oracle: PL/SQL, DB2: DB2 SQL, ...) da es z.b. auch kein "BASIC" auf den gängigen plattformen gibt sehe ich das aber auch nicht als problem an wenn ich die Option "SQL" so interpretiere.

SQL fängt nicht mit SELECT an und hört mit ORDER BY auf! ;P Hier beispielhaft etwas Quelltext aus irgendnem SQL Programming Tutorial: declare @Part_Id int declare @Category_Id int declare @Desc varchar(50) create table PART (Part_Id int, Category_Id int, Description varchar(50)) set @Part_Id = 0 set @Category_Id = 0 while @Part_Id < 2 begin set @Part_Id = @Part_Id + 1 while @Category_Id < 3 begin set @Category_Id = @Category_Id + 1 set @Desc = 'Part_Id is ' + cast(@Part_Id as char(1)) + ' Category_Id ' + cast(@Category_Id as char(1)) insert into PART values(@Part_Id, @Category_Id, @Desc ) end set @Category_Id = 0 end select * from PART drop table PART In der Frage stand allerdings auch nichts von Dateien. Aber selbst wenns Dateien sind schließt das SQL nicht komplett aus. Über OleDb/ODBC kann man auch ganz einfach SELECT Statements auf z.B. CSV oder XLS dateien absetzen. Ob das dann unbedingt viel performanter ist als ne selbstgebaute lösung sei dahingestellt. Allerdings muss man in C++ schon sehr clever(*) programmieren um an die Performance (die in der Aufgabenstellung ja sehr unterstrichen wurde) von SQL + Datenbank Server zu gelangen. Das sind halt genau die Technologien die für große Datenmengen entwickelt wurden. Vielleicht waren die Messdaten ja doch nicht so "umfangreich" und deshalb C++ ;P Abgesehen von dieser Aufgabe bin ich auch mit der IHK Lösung von Aufgabe 4.4 aus den gleichen gründen wie ykcuhc und flowx nicht so ganz Einverstanden. Mit dem Rest komm ich aber klar. (*) cleverer als man es von nem fachinformatiker erwarten sollte

Ich hab SQL (3) als Lösung genommen, befürchte aber das C++ von der IHK gemeint war. Ich bin allerdings schon der Ansicht das man mit SQL bzw. Transact-SQL (was genaugenommen vllt. nicht das gleiche ist) Programme erstellen kann (Stichwort: Stored Procedures) und das C++ um längen geschlagen wird was die Schnelligkeit/Antwortzeit bei *großen* Datenmengen betrifft. Genaugenommen würd ich SQL für die schnelle Aufbereitung / Auswertung der Daten nehmen (was IMHO gefragt war) und dann C++ (bzw. eher C#/VB .NET) zur Darstellung (Bildschirm oder Excel File, etc..) mal schauen..

d'oh..

2.2b) wie kommt man da auf 690? hab P = U * I = 12V * 7A = 84 VA für 1h?