Frage von Marco224, 110

Unterschied zwischen NOT NULL und NULL?

Hallo,

ich bin gerade dabei erste SQL-Befehle über phpmyadmin zu schreiben.

die frage steht eigentlich schon oben, ich würde gerne wissen was der Unterschied zwischen NOT NULL und NULL ist?

Bitte nicht in Fachchinesisch :) DANKE!

Antwort
von UweKeim, 61

NULL schreibst du, wenn du etwas nicht weißt aber auch nicht einfach ein Leerzeichen hinschreiben möchtest. 

z.B. wenn du eine Tabelle adresse hast aber nur den Namen und nicht die Telefonnummer weißt:

insert into adresse values ('Name', NULL);

Wenn du aber ein Leerzeichen einfügst anstatt eine NULL, dann hat diese Person leider keine Telefonnummer:

insert into adresse values ('Name2', ' ');

Willst du jetzt alle Personen wissen, von denen du die Telefonnummer nicht kennst (alle mit NULL), dann schreibst du:

select * from adresse where telefonnummer IS NULL;

Willst du alle Namen wissen, von denen du die Telefonnummer weißt oder du weißt, dass sie keine Telefonnr. haben:

select * from adresse where telefonnummer IS NOT NULL;

Hoffe, du hast es einigermaßen verstanden :)

Kommentar von mepeisen ,

Und bezogen auf die Tabellendefinition selbst:

NULL bedeutet: Die Spalte darf auch "leer" sein (im Sinne wie UweKeim es erklärt hat)

NOT NULL bedeutet: In der Spalte muss zwingend immer ein gültiger Wert stehen und sei es bei Textspalten beispielsweise ein Leerzeichen oder auch ein Leerstring

Kommentar von UweKeim ,

Ja, z.B. darf der Primary Key niemals NULL sein aber der wird immer so definiert, dass er nicht NULL sein kann.

Antwort
von TomRichter, 39

> Unterschied zwischen NOT NULL und NULL

Wenn Du von einem Datensatz (= eine Zeile der Tabelle) nur einen Teil der Werte kennst, kannst Du diesen Datensatz trotzdem in die Tabelle schreiben und die unbekannten Werte dabei einfach weglassen - aber nur bei Feldern, die nullable sind, also mit NULL definiert wurden. Wobei es von der konkreten Datenbank abhängt, was sie nimmt, wenn man weder NULL noch NOT NULL angibt. Beispiel

Tabelle (Kundennummer, Name, Geburtsdatum), aber der Geburtstag eines neuen Kunden ist unbekannt. Wenn Geburtsdatum nullable ist, kein Problem, legst Du einen neuen Datensatz an nur mit Nummer und Name.

Wenn aber Geburtsdatum NOT NULL ist, ergibt der Versuch, einen Datensatz ohne Geburtsdatum einzutragen, einen Fehler. Als Krücke kann man dann ein Datum definieren, das die Bedeutung "unbekannt" haben soll. 1.1.1800 wäre ein guter Wert, sofern die Datenbank nur über lebende oder vor kurzem verstorbene Personen geht. Aber anders als bei NULL gilt das nur so lange als "unbekannt", wie der Programmierer beim Schreiben seiner Datenbankabfrage daran denkt, dass er das nicht als echtes Datum ansehen darf.

Eine Abfrage auf Volljährigkeit, die prüft, ob das Geburtsdatum mehr als 18 Jahre in der Vergangenheit liegt, funktioniert nur mit der zusätzlichen Prüfung AND Geburtsdatum != '1.1.1800'


Antwort
von wotan38, 31

NOT NULL kann auch ein Merkmal für ein Datenfeld bei der Definition einer Tabelle sein. Für Datenfelder, die für den Primärschlüssel oder einen eindeutigen Index verwendet werden muss NOT NULL angegen werden und bedeutet, dass in diesen Feldern immer ein realer Wert stehen muss. Ohne diese Angabe kann man ein Feld auf NULL setzen, was soviel bedeutet, dass für dieses Feld kein Wert existiert.

Bei der Abfrage muss man ggf genau angeben, was mit den Feldern, die auf NULL gesetzt sind geschehen soll.

Wenn man z.B. ein Feld alternativ auf gleich einem Wert und dann auf ungleich dem selben Wert abfragt, bekommt man beim Ergebnis die auf NULL stehenden Werte weder bei der einen noch bei der anderen Abfrage. Um diese Werte zu bekommen (falls man sie haben möchte) muss man gezielt danach fragen: WHERE (feld = 0 OR feld IS NULL).

Wenn man z.B. jeden Tag die Temperatur misst und dies in einer Tabelle dokumentiert, würde man eine vergessene Messung mit NULL angeben können, was dann soviel bedeuten würde, dass es für diesen Tag keine Messung gibt. Bei der Berechnung der Durchschnittstemperatur würde dieser Tag nicht berücksichtigt. 

Antwort
von cg1967, 20

ich bin gerade dabei erste SQL-Befehle über phpmyadmin zu schreiben.

Ich tippe ja, daß du dich z. Z. mit DML und nicht mit SQL beschäftigst.

die frage steht eigentlich schon oben, ich würde gerne wissen was der Unterschied zwischen NOT NULL und NULL ist?

Ein Feld, welches auf NOT NULL gesetzt ist, muß einen dem Feldtyp entsprechenden Wert erhalten. Z. B. wäre bei einem String ein Leerstring "" ein dem Feldtyp entsprechender Wert, bei einem Integer 0. Was nicht funktioniert ist die Zuweisung von NULL an ein solches Feld.

Wenn du dich dann mal mit SQL beschäftigst kannst du Felder, welche auf NULL gesetzt werden dürfen, mit IS NULL bzw. IS NOT NULL abfragen. Bitte laß dies sein, falls es sich vermeiden läßt. Ich mußte so eine Lösung einmal verwenden (und der Feldtyp war TEXT (unter Oracle), da gibts keine "="-Vergleich), da für die Produktivdatenbank kein Admin erreichbar war, dieses Feld aus unerklärlichen Gründen angelegt und nicht genutzt war und die Lösung vor einem 1.1. online gehen mußte.

Kommentar von TomRichter ,

> Bitte laß dies sein, falls es sich vermeiden läßt

Kein guter Rat. "Mach Dich schlau, bevor Du eine Datenbank designst" wäre mein Vorschlag.

Vermeiden kann man eine NOT NULL Definition fast immer - außer bei Feldern, die zum Primärschlüssel gehören. Aber in den Fällen, in denen aus Sicht der Anwendung ein Feld bestückt sein muss (beispielsweise Tabelle Zustelladresse, Feld Ort), erschwert es die Programmierung nur, wenn die Datenbank ein solches Feld mit NULL zulässt.

Antwort
von Suboptimierer, 98

NULL beschreibt einen uninitialisierten Zustand. 

In dem Speicherbereich kann alles Mögliche drin stehen. Die Datenbank liest aber nicht den genauen Inhalt aus, sondern drückt mit NULL aus, dass man mit dem Inhalt nichts anfangen könnte, weil da beliebiges Wirrwarr drin stehen könnte.

NULL muss häufig gesondert abgefragt werden, also mit IS (NOT) NULL. 
= NULL oder <> NULL funktionieren i. d. R. nicht.

Kommentar von wotan38 ,

Bei Null gibt es keinen Speichernbereich, weil nichts gespeichert wird. Genau das besagt das Attribut NULL. Es ist auch kein beliebiges Wirrwarr oder  "alles Mögliche" vorhanden.

Ein Datensatz kann ein Feld enthalten, für das kein Wert existiert, weil kein Wert angegeben wurde. Bei der Definition jedes Feldes muss festgelegt sein, ob NULL zugelassen wird oder nicht. NULL selbst ist kein Wert, sondern ein Zustand. Es kann weder einem Wert gleich noch ungleich sein.

Antwort
von Sawascwoolf, 110

Not Null (Nicht Leer) überprüft ob ein Feld nicht leer ist.

NULL (Leer) überprüft ob ein Feld leer ist.

Kommentar von Sonie1969 ,

die echten coder fallen auf.

Antwort
von ThomasJNewton, 42

Es ist eben ein Unterschied, ob ein Feld den Initialwert hat oder gar keinen Inhalt.
Der Initialwert ist 0 für ein numerisches Feld, und Leerzeichen für Textfelder.
NULL wird meist als HexNullen dargestellt.

Soweit ich weiß, gibt es die Moglichkeiten, Felder nicht zu initialisieren nicht in allen Datenbanksystemen, mit Sicherheit ist es nicht immer für alle Felder erlaubt, für Primärschlüssel wäre es, wie erwähnt, tötlich.

Der tiefere Sinn erschließt sich mir auch nicht ganz, denn NULL muss ja auch auf die Platte geschrieben werden, sie wird nicht an der Farbe der Bits erkannt.
Perfomancevorteil ergeben sich vielleicht bei der Änderung der Tabellendefinition, wenn Felder zugefügt werden.
Dafür hat man nachher den Ärger, wenn man neben 0 oder SPACE immer noch NULL in seine SELECTs aufnehmen muss.

Denn SELECT ... FROM ... WHERE BETRAG = 0 OR BETRAG <> 0 liefert dann eben nur einen Bruchteil der Datensätze.

Wenn du also eine Datenbank enwirfst, lass den Quatsch.

Kommentar von ceevee ,

Der tiefere Sinn erschließt sich mir auch nicht ganz... Wenn du also eine Datenbank enwirfst, lass den Quatsch.

Angenommen, wir haben eine Datenbank, in der wir Umfrageergebnisse speichern und dort haben wir u.a. ein Feld "istAutofahrer". Dieses Feld ist ein boolean und kann dementsprechend die Werte "true" oder "false" annehmen. Jetzt können die Teilnehmer bei der Umfrage aber auch ihre Stimme enthalten. Dann kann man in die Datenbank weder "true" noch "false" schreiben, andere Datentypen nimmt man als cleverer Programmierer nicht, weil man dann Probleme mit Fehleingaben kriegen könnte bzw. diese ausprogrammieren müsste. Der eleganteste Weg, um dieses Problem zu lösen, wäre also ein nullable boolean mit den Werten "true", "false" und "NULL". 

Kommentar von ThomasJNewton ,

Das ist nicht clever, sondern ein Trick, oder ein Betrug.

Schon als ich mit Computern angefangen habe, war der Kampf um jedes kleinste Bit Speicherplatz Vergangenheit.

Es gibt keine Begründung, die Realität nicht in der Datenbank abzubilden.
Wenn es drei Möglichkeiten gibt, Autofahrer, Nichtautofaher oder Aussageverweigerer, dann gibt es keinen Grund, das nicht in der Datenbank als genau diese drei Möglichkeiten abzuspeichern.

Dazu gibt es auch vorgegebene Möglichkeiten, wenn dir Datenelemente, Domänen und Festwerte etwas sagen.

Von dem gesparten Bit wirst du sicherlich kein Softwaremilliardär, denn ein Bit kostet heutzutage etwa soviel wie einer von der Palette gefallene Null im Mathemarkt.

Ein Programmier sollte nicht clever oder elegant sein, sondern was "wegschaffen".
Und eines der Hindernisse dabei sind Erbstücke von cleveren und eleganten Programmierern.

Und was ist wohl die Arbeit des Programmierers?
Etwas auszuprogrammieren.

Und die Verfechter eines

nullable boolean

sind nach meiner Meinung reif. Für die Klinik.

Kommentar von mepeisen ,

sind nach meiner Meinung reif. Für die Klinik.

Leute, die solche Aussagen treffen, sind reif für die Klinik. Ich habe dir mal in der anderen Antwort einen vielleicht besseren Anwendungsfall gepostet.

Natürlich gibt es immer mehrere Wege zur Lösung. Deswegen ist es aber noch lange nicht so, dass einer der Wege grundsätzlich des Teufels ist. Was machst du denn, wenn das Boolean auf Null stehend ausdrücken soll, dass die Auswertung für diese Person noch nicht erfolgt ist? Wenn es aus Performance-Gründen einen separaten periodischen Job gibt, der dann eine Auswertung vornimmt und erst den tatsächlichen Inhalt des Flags "Autofahrer" oder "Nicht-Autofahrer" ermittelt?

Dann wirst du womöglich sagen, dass du dir ein zweites Flag hältst, in dem dann drin steht, ob das Boolean bereits berechnet wurde oder nicht. Und da sage ich dann "Nein, das ist Betrug und führt dazu, dass du in jedem Select dieses zweite Flag mit abprüfen musst".

Kommentar von ThomasJNewton ,

Dann nehm ich halt kein "Boolean".

Das ist neumodischer Schnickschnack.
Zu meiner Zeit hieß das Ja, Nein, oder "keine Meinung".

Der Entwirf von Datenbanken und Datentypen hat sich der Realität anzupassen, nicht umgekehrt.

Oder warum wohl schaffen die Programmierer mit altertümlichen Techniken das Mehrfache der Theoretiker?

Ich setze halt keine Flags, ich speicher Daten, und werte sie aus.
Und zwar erfolgreich, während du noch ein Framework aus dem Internet lädst.

Kommentar von mepeisen ,

Der Entwirf von Datenbanken und Datentypen hat sich der Realität anzupassen, nicht umgekehrt.

Und deswegen behauptest du, dass das Konzept des NULL Quatsch ist? Du hast dir gerade gepflegt selbst widersprochen bei deinem lächerlichen Versuch, mich zu provozieren bzw. zu flamen...

Wie schön, dass es solche unfähigen Entwickler wie dich gibt. So Leute begegnen mir täglich. Zum Glück überleben sie in der Branche nicht lange. Am Ende siegt dann doch die Wahrheit oder die Realität und nicht derjenige, der nur am lautesten irgendeinen Blödsinn vor sich hin poltert.

In diesem Sinne: Hat Spaß gemacht, mit dir zu spielen. Geh mal weiter an deinen Schreibtisch und entwerfe Datenbanken für die Realität. Ich realisiere in dieser Zeit lieber etwas Brauchbares und verdiene Geld damit.

P.S.: Ich beschäftige mich beispielsweise schon seit 20 Jahren mit Performance-Analysen in Datenbanksystemen. Und ich habe schon extrem viel erlebt, was Leute wie du fabriziert haben. Und am Ende waren dann doch die, die am lautesten gepoltert haben, dass ihr normalisiertes Datenbankmodell das beste der Welt sei, diejenigen, die ganz kleinlaut gekündigt haben (oder rausgeworfen wurden) und verschwunden sind, um woanders Unternehmen in den Ruin zu treiben.

Kommentar von ThomasJNewton ,

Nun mal ganz ruhig:

Man kann sich gern mal streiten, und auch gern mal über bestimmte "Schulen" herziehen.
Am Ende haben wohl beide nicht ganz unrecht.

Und um das klar zu stellen, ich habe niemals dich persönlich gemeint, wenn ich gelästert habe. Wenn das bei dir so ankam, tut es mir leid.
Und nur für den Fall ist eine ganz direkte Bezugnahme auf mich eine Retourkutsche. Ansonsten ein neues Fass.

Eins ohne Boden wohlgemerkt. Auch ich habe lange produktiv gearbeitet, in erfolgreichen Projekten, meist direkt beim Kunden.
Und ich wurde nie rausgeworfen, aus keiner Firma und nicht mal aus einem Projekt.

Also nochmal:
Wenn ich irgendwas als krank bezeichnete, und die Verfechter, war das nur eine Überspitzung.
Damit meine ich ernsthaft keinen Menschen, und erst recht nicht dich.

Kommentar von mepeisen ,

Nun mal ganz ruhig

Du bist doch derjenige, der hier persönlich wurde. Du hast auch nicht irgendetwas als krank bezeichnet, du hast geschrieben, dass Leute, die so etwas machen, in die Klinik gehören. Du hast völlig verfehlt versucht, mich und meine Eltern zu beleidigen. Du bist derjenige, der hier persönlich wird.

Und nun entschuldige dich vernünftig und nicht so halbgar, sonst melde ich dich wirklich bei den Admins. Leute sind hier schon wegen weniger rausgeflogen.

Mag dir egal sein, mir aber nicht.

Kommentar von ThomasJNewton ,

Hinter dem "Nun mal ganz ruhig" steht ein Doppelpunkt. Damit habe ich aussagen wollen, dass es mein Versuch war, die Sache ruhig anzugehen. Ich wollte nicht dich zur Ruhe auffordern.

Und ich kann es nur wiederholen, ich habe keinen Menschen persönlich gemeint, weder dich noch andere.
Ich meine es auch nicht ernsthaft, dass irgendjemand in die Klinik gehört.

Und für die Aussage über deine Eltern in einem anderen Zweig bitte ich an dieser Stelle noch mal ausdrücklich.um Entschuldig. DIe war in der Tat unangemessen und beleidigend.

Kommentar von wotan38 ,

Es gibt gute Gründe NULL dort zuzulassen, wo das Sinn macht und man kann es natürlich auch umgehen. Wer NULL aber grundsätzlich ablehnt, hat irgendwas nicht verstanden.

Wie überall gibt es auch in der Programmierung sehr gescheite Leute, die alles besser wissen und ihre Ansicht jedem aufzwingen wollen. Zum Glück muss man nicht alles mitmachen. So halte ich z.B. wenig von einer sog. eleganten Programmierung. Beim Testen und Fehlersuchen führt die scheinbar umständliche Art schneller zum Ziel, weil sie einfacher zu durchschauen und zu überprüfen ist. Aber als den Stein der Weisen würde ich das deshalb nicht ansehen. Kann jeder so machen wie er am besten klarkommt.

Kommentar von mepeisen ,

NULL wird meist als HexNullen dargestellt.

Nein. Es wird in nahezu allen gängigen Sprachen als exakt das ausgedrückt, als null. (Wahlweise groß- oder kleingeschrieben). Hex 0 bzw. 0x00 meinst du wohl, ist dezimal 0 und damit ein valider Wert.

Es gibt Zahlensysteme, beispielsweise in Cobol, wo tatsächlich der Wert 0x00 bedeutet "nicht initialisiert". Aber das sind gemessen an der heutigen Zeit schlichtweg Exoten.

 Alterative Schreibweise für null ist invalid oder undefined.

Der tiefere Sinn erschließt sich mir auch nicht ganz, denn NULL muss ja auch auf die Platte geschrieben werden, sie wird nicht an der Farbe der Bits erkannt.
Perfomancevorteil ergeben sich vielleicht bei der Änderung der Tabellendefinition, wenn Felder zugefügt werden.
Dafür hat man nachher den Ärger, wenn man neben 0 oder SPACE immer noch NULL in seine SELECTs aufnehmen muss.

Dieser ganze Absatz ist leider völliger Quatsch. Das Einlesen erfolgt auch in DB-System üblicherweise als gesamter Datensatz. Ob dann ein Byte mehr oder weniger belegt ist, wirkt sich in der Performance üblicherweise nicht aus. Oder nur dann, wenn man zufällig die Standardgröße eines sogenannten Chunks (heisst auch je nach Datenbanksystem anders, manche nennen es Page usw.)sprengt.

Wenn du also eine Datenbank enwirfst, lass den Quatsch.

Das ist allerdings wiederum Quatsch. Es genug Anwendungsfälle, wo es wichtig ist, eine Spalte NULLABLE zu machen, also den Wert NULL zuzulassen.

Neben den von cevee genannten Anwendungsfall gibt es noch einen weiteren: Wenn ich Informationen an mehreren Iterationen speichere (also hierarchisch), kann das Bedürfnis bestehen, zu registrieren, was ich überschrieben habe und was nicht. Wenn ich an einer Gruppe ein Flag habe, dann ist es (als oberstes Element) nicht nullable. Es hat immer true oder false als Wert. Wenn ich nun als Teil dieser Gruppe (=Als Benutzer) die Möglichkeit habe, dies zu überschreiben, dann habe ich drei Ausprägnungen: 1. Wert nicht überschrieben (=null), 2. Wert überschrieben mit Ja (=true), 3. Wert überschrieben mit false (=nein). SQL hat dann dafür sogar relativ gute Möglichkeiten, auf so etwas individuell zu reagieren. Man nehme beispielsweise einmal COALESCE.

Kommentar von ThomasJNewton ,

Ich hab meine ersten Programme geschrieben, als deine Eltern noch in die Windeln geschissen haben. Außer sie waren Spätentwickler.

Also blamier dich nicht weiter. Die Null, NULL oder null ist ein Symbol, und steht so weder in einer Datenbank noch in einem Programm.

Oder anders:
Wer von uns beiden hat je Datenbankzugriffe in Assembler programmiert? ok; es war ein Makroassembler.

Kommentar von TomRichter ,

> ok; es war ein Makroassembler.

Und die Datenbank war keine SQL-Datenbank, und das macht den großen Unterschied.

Kommentar von ceevee ,

Ich frag mich sowieso, was ThomasJNetwton mit seinem letzten Beitrag so richtig aussagen will... für mich klingt der Beitrag wie "Ich hab zwar nix sinnvolles beizutragen und auf mpeisen's Kommentar kann ich erst recht nicht fachlich eingehen, aber ich bin alt und dementsprechend der beste Programmierer weit und breit hier. Guckt mal alle, wie toll ich bin! "

Ich hab das Gefühl, dass er von modernen Programmierkonzepten (wobei Datenbanknormalisierung anscheinend bei ihm auch schon ein modernes Konzept ist), nicht versteht. Und weil er sie nicht versteht, verteufelt er sie.

Kommentar von ThomasJNewton ,

Ja, richtig.

Ich wollte auch nur andeuten, dass ich schon lange Erfahrungen sammle.

Und neueren Entwicklungen keineswegs ablehnend gegenüberstehe.
Ich habe recht viel mit SQL gearbeitet, und auch mit Objektorientierung. Und ich sehe durchaus die Vorteile.

Ich sehe aber auch Moden. Die so grundlegende Neuerungen sind, dass jeder in 5 Jahren arbeitslos ist, wenn er die nciht mitmacht.
Demnach wäre ich schon mehrmals arbeitslos geworden.

Kommentar von mepeisen ,
Ich hab meine ersten Programme geschrieben, als deine Eltern noch in die Windeln geschissen haben. Außer sie waren Spätentwickler.

Normalerweise müsste man so einen Kommentar nehmen und bei GF-Admins melden. Die haben hier extra so einen Button für solche Kommentare, wie du den fabrizierst.

Also blamier dich nicht weiter

Nun, diese Empfehlung gebe ich mal ganz gepflegt an dich weiter.

Die Null, NULL oder null ist ein Symbol, und steht so weder in einer Datenbank noch in einem Programm.

Wenn man sich weit aus dem Fenster lehnt, sollte man aufpassen dass es geschlossen ist. Ansonsten könnte es passieren, dass man hinausfällt. Definiere mir bitte zuerst mal, was ein Programm ist. Du wirst gewaltige Schwierigkeiten mit dieser These haben. Denn wenn man Scriptsprachen als Programm ansieht, dann steht dämlicherweise (da Scriptsprachen üblicherweise nicht compiliert ausgeliefert werden) das exakt so in Text auch im Programm.

Sorry, dass ich dir auf dieser Ebene komme, aber wer versucht mich lächerlich zu machen, den mache ich mal kurzerhand lächerlich.

Wer von uns beiden hat je Datenbankzugriffe in Assembler programmiert?

Nur weil du denkst, dass du etwas kannst, was sich Assembler nennt, hast du noch lange keine Ahnung. Das ist mittlerweile auch den anderen hier aufgefallen. Deine Ahnungslosigkeit versteckst du leider hinter Versuchen, mich persönlich irgendwie anzugreifen und machst dich damit nur lächerlich.

Ich spreche übrigens fließend Assembler in den verschiedensten Dialekten. Und damit habe ich nicht angefangen. Gelernt habe ich mein Assembler-Handwerk, als der VC-20 rauskam mit dem 6502. Neben verschiedensten Ausflügen auf verschiedene Motorolas wechselte ich zur X86 Architektur und habe die verschiedensten Prozessoren und Systeme mitgemacht. Mittlerweile aber nur noch Hochsprachen. Kannst du zurück rechnen, wie das mit dem Alter wohl sein müsste?

So viel zu deiner Kompetenz, denn offenbar hast du davon nicht viel. Und das liegt nicht daran, dass du (nur?) Assembler kannst. Das liegt daran, dass du eine absolute Grundregel der Informatik bis heute nicht gelernt hast: Es gibt kein "Absolut falsch" und "Absolut richtig" in dem Weg, wie man zu einem Ergebnis kommt. Es gibt ggf. ein "Schnell" oder "Langsam", wobei man das auch bei modernen Systemen mit Vorsicht genießen muss (gesondertes Thema). Es gibt ein "geeignet" und ein "ungeeignet". Und vor allem gibt es in der modernen Softwareentwicklung exakt eines: Ein "Gut dokumentiert" oder ein "schlecht dokumentiert".

So und nun das allerletzte Beispiel: Joins. Wenn du nicht weißt, was das mit der Fragestellung nach Joins zu tun hat, hast du in der Grundschule nicht aufgepasst, als die Mengenlehre dran kam. Insofern: Du bist wohl gedanklich in der Grundschule stehen geblieben trotz deinem Wissen über Marko-Assembler.

Keine passende Antwort gefunden?

Fragen Sie die Community