Beiträge von flaminio

Es gibt sicher Unterforderung, und manche fallen durchs Raster, gerade, wenn sie nicht brav und angepasst funktionieren. Aber daraus gleich zu machen, dass Hochbegabte generell nicht gebraucht oder systematisch weggedrückt werden, wäre mir zu glatt.

IMHO hängt viel davon ab, ob Begabung überhaupt erkannt wird und ob jemand daraus auch etwas Arbeitsfähiges machen kann. Nur schnell denken reicht halt nicht automatisch. Dennoch kommt man nicht an Ausdauer, soziale Reibungsfähigkeit, Fachwissen und manchmal schlicht jemanden, der einen nicht sofort als Störung sieht, herum. Genau da kann Schule oder Uni viel kaputtmachen, aber eben auch viel auffangen.

Wenn jemand auch in der Schule geistig dauernd untertourig fährt, sucht er sich irgendwann Nebenschauplätze. Imho sollte man es flexibler und damit einhergehend schneller vorangehen. Und nein, nicht als VIP-Behandlung, sondern, damit Potenzial nicht vergammelt. Nur, könnte man die stillen und die störenden Begabten früh genug erkennen?

Ich würde da nicht wild weiter alles umbauen, sondern erst mal stumpf die Testnamen abarbeiten. Das sieht bei dir nach kleinen Syntax- und Erwartungsfehlern aus, die dann natürlich gleich viele Folgetests reißen.

Was mir sofort auffällt, ist, dass in mehreren CREATE TABLE-Blöcken vor der schließenden Klammer noch ein Komma nach dem letzten Constraint steht. Das kann dir schon die ganze Tabelle kaputt machen. Dann würde ich Umlaute in Spaltennamen vermeiden, weil nach Test wird vermutlich exakt auf Attributnamen geprüft, und dann ist das in Kombination mit der Groß-/Kleinschreibung schnell Gift.

Bei Messwert würde ich besonders schauen. Das Beispiel-Insert nutzt (ID, Zeitpunkt, Messwert, Typ, Art) und steckt ('41', 'm') in den Struct. Also muss die Struct-Definition wirklich exakt dazu passen. In DuckDB greift man auf Struct-Felder eher sauber mit Punktnotation zu, z. B. Messwert.Einheit, nicht mit irgendeiner Syntax, die aus anderen SQL-Dialekten kommt.

Falls laut ER-Diagramm jeder Messwert zwingend zu einer Station gehört, könnte auch Station_ID zum Problem werden, weil in dem Fall fehlt dann NOT NULL. Bei Richtung BETWEEN 0 AND 360 musst du außerdem bedenken, dass, wenn es in Richtung NULL ist, darf der Check nicht versehentlich andere Typen stören.

Ich würde bei dem Thema etwas sauberer zwischen HDD, SSD und Smartphone trennen. Überschreiben ist imho insbesondere bei den alten magnetischen Festplatten ziemlich nachvollziehbar, weil die Daten dort eben klassisch auf Plattern liegen. Aber bei SSDs, USB-Sticks und Speicherkarten hat sich das bei mir immer komplexer als es mir lieb war gestaltet. Da ist Secure Erase bzw. ein Hersteller-Tool oft der passendere Weg.

Und das ist der Grund, wessen dem ich vorher immer ein Backup mache und dann erst checke, ob wirklich der richtige Datenträger erwischt wurde. Was ich auch schon mitbekommen habe, ist, dass ein Freund nur schnell eine externe Platte löschen wollte und plötzlich die falsche erwischt hat. Die Folge war ein Nervenzusammenbruch, und für den Verkauf würde ich zusätzlich Verschlüsselung vorher nicht unterschätzen. Wenn ein Gerät schon sauber verschlüsselt war und danach zurückgesetzt bzw. der Schlüssel verworfen wird, ist das oft sinnvoller, als hektisch irgendwelche Tools laufen zu lassen. Bei sehr sensiblen Daten oder Defekten bleibt am Ende aber nur eine fachgerechte physische Vernichtung.