SQL Datentyp für Jahr (Oracle)?
Mein Professor benutzt für YEAR den Datentyp INTEGER anstatt SMALLINT.
Hat er das einfach verpeilt, oder ist das so üblich, wenn ja warum?
Weil dass eine Datenbank bis zum Jahr 32767 überlebt kann man doch echt nicht erwarten, oder hat das einen anderen Grund?
5 Antworten
Mir hat mal jemand gesagt, dass Lehrer und auch Professoren oft nicht so fitt in der Thematik sind, wie Leute aus der Wirtschaft. Das hat einen ganz einfachen Grund: Die Leute aus der Wirtschaft werden dafür bezahlt, sich mit der Thematik auseinanderzusetzen und sich ggf. auch tief darin einzuarbeiten. Lehrer werden für das Lehren bezahlt, bei Professoren kommt vermutlich noch etwas mehr dazu, da geht viel Zeit verloren.
Das heißt nicht, dass dein Professor nichts kann, sondern nur, dass Du nicht jedes Detail als Gesetz betrachten solltest.
Und natürlich ist deine Argumentation korrekt, aber ...
Bei Typen muss man auch die Lesbarkeit, Wartbarkeit und Sicherheit abwägen, das ist z.B. der Grund, warum im normalen Code (kein SQL) in vielen Fällen einfach nur Integer genutzt wird, obwohl vielleicht ähnliche aber andere Typen besser sind. Viele verschiedene Typen können den Code komplexer machen, deshalb greifen viele einfach nur auf Integer zurück. So nutzt jeder den selben Zahlentyp und wenn Du dann einen Wert brauchst, der eine Zahl ist, musst Du nicht erst den Datentyp nachschauen, um damit arbeiten zu können.
Ich persönlich würde dazu raten: Nimm einfach Integer, außer Du hast konkrete Gründe dagegen.
Bei SQL bzw. Datenbanken könnte das z.B. der Speicherbedarf sein, wenn Du zig Millionen Datensätze speichern muss, wird das sehr relevant. Wenn Du aber nur kleine Datenmengen hast (und ja, ein paar 100k sind noch klein), ist das ziemlich irrelevant.
Genso gibt's bei Datenbanken aber auch den Gesichtspunkt, ob das Datenschema mal angepasst werden muss. Stell dir die Frage: Tut es weh, wenn man später von Integer auf SmallInt (z.B. wenn 100 Millionen Datensätze erwartet werden) umstellen muss? Bei Datenbanken, die sehr lange leben und daher eine vermutlich umfangreiche Evolution erleben werden, kann das oft ein klares JA! sein, dann sollte man lieber drei mal drüber nachdenken. Z.B. bedeutet Integer auf SmallInt potentiellen Datenverlust, vielleicht nicht bei Jahreszahlen, aber bei anderen Werten kann das passieren.
In einem produktiven Projekt würde ich für die Jahreszahl auch SmallInt nutzen, aber nicht nur, weil ich damit Speicher sparen kann, sondern auch um einen anderen Typ zu haben.
Etwas ähnliches mache ich z.B. bei Prozentwerten, die sind bei mir immer Float, obwohl auch Double möglich wäre, aber auf diese Weise erreiche ich: "Der Typ ist anders, denk nach, das hat einen Grund!"
Es gibt z.B. auch das DesignPattern "Domain Specific Value", was in genau diese Kerbe schlägt. Man definiert einen komplett neuen Typ, einfach nur, damit es ein neuer Typ ist und der nicht mit den Standard-Typen kompatibel ist. Ein gutes Beispiel, wo das Gold wert ist, sind Brutto- und Netto-Werte bei Finanzen, die darfst Du nicht vertauschen und verschiedene nicht kompatible Typen können das sicherstellen.
Du merkst, es gibt viele Betrachtungswege, das Thema klingt einfach, man kann es aber beliebig groß aufziehen ;) Es ist einfach immer eine Frage der Abwägung und man muss sich immer die Situation anschauen.
In einer Vorlesung wird dein Professor sich aber hoffentlich auf die Vorlesung konzentrieren und nicht groß über Datentypen nachdenken. Umgekehrt auch ihr: Ihr sollt das Grundprinzip verstehen und nicht über eher nebensächliche Datentypen grübeln.
Frag einfach mal nach, erkläre ihm deine Argumente und ggf. entsteht eine interessante Diskussion, vielleicht lernen er und die restlichen Studenten auch etwas.
Möglicherweise ist es einfach Gewohnheit. Deine Argumentation ist natürlich richtig aber der Mensch ist ein Gewohnheitstier
Man nimmt halt den Datentyp der zu dem Wertebereich passt den man darstellen möchte. Aber wenn ich eine Ganzzahl brache würde ich auch ohne groß nachzudenken Integer nutzen. Ob da nun in einer überschaubaren DB 2 oder 4 Bytes für den Wert belegt werden ist mir da nicht so wichtig. Ich weiß halt das Int eine Ganzzahl ist und ehe ich da die Doku bemühe um zu schauen ob ein Datentyp ein wenig sparsamer ist - eher nicht. Aber im Prinzip hast du schon Recht das ein SMALLINT bei aktuellen Jahreszahlen hier sicher ausreicht.
Mein Fazit: Autopilot an Ganzzahl = Integer und Fertig.
Es macht einfach keinen spürbaren Effizienzunterschied (mehr), daher ist ein Datentyp in vielen Sprachen zum Standard-Ganzzahltyp geworden - in SQL eben INTEGER.
Prinzipiell hast du natürlich Recht, dass man ein bisschen Speicher sparen und stattdessen mit SMALLINT 2 Byte weniger als mit INTEGER belegen könnte.
Üblicherweise ist das aber aus zwei Gesichtspunkten irrelevant:
- Diese 2 Byte sind nicht spürbar. Mittlerweile haben Computer so astronomisch viel Arbeitsspeicher, dass es auf wenige Bytes hin oder her nicht mehr ankommt. Das Quäntchen Zeit, das man damit sparen könnte, fällt normal nicht merklich ins Gewicht.
- Normalerweise kommt es auch gar nicht so extrem auf Geschwindigkeit an. Wenn ein System (im Extremfall) mal eine Sekunde länger braucht, dann ist das eben so. Die Anzahl der Anwendungen, in denen so etwas gravierend ist, halten sich in Grenzen und für diese lohnt es sich dann oft am meisten, einfach einen Rechner mehr hinzustellen statt viel Arbeitszeit darauf aufzuwenden, die effizientesten Datentypen zu verwenden (immerhin hat ein Integer Overflow die Ariane 5 zum Absturz gebracht).
Dasselbe kann man auch in Java beobachten. Alle Datentypen abseits von boolean, int und double haben ihre beste Zeit hinter sich. Ja, für kleine Zahlen braucht man womöglich keine 4 Byte wie ein int sie bereitstellt, sondern das eine Byte in einem byte die 2 Byte in einem short würden genügen, aber es ist einfach egal. Heutzutage kann man in einem gewissen Maße großzügiger Speicher verteilen als noch vor vielen Jahren.
Datentypen so zweckzuentfremden, halte ich arg für bad practise. Mit deinem anderen Punkt hast du aber natürlich Recht, deswegen schrieb ich ja normalerweise. Wenn man gewisse Dimensionen erreicht, muss man sich über so etwas Gedanken machen. Das ist aber eher die Einzelfall.
Wieso Zweckentfremden?
Natürlich soll kein Datentyp falsch genutzt werden (z.B. Zahlen als String), aber wenn die Wahl zwischen mehreren Zahlentypen besteht, ist das keine Zweckentfremdung.
Z.B. Float ist ein ganz normaler und valider Typ für Prozentwerte.
Und was ich bezüglich Brutto vs. Netto meine, ist auch keine Zweckentfremdung, sondern hat sogar einen Namen "Domain Specific Values" und kann (je nach Anwendung) den blanken Arsch retten :D
Zumindest ist es insofern Zweckentfremdung, als dass die Existenz verschiedener interner Datentypen als verschiedene Repräsentanten desselben Objekts nicht darauf abzielt, ihnen durch die kontextabhängige Verwendung implizite Semantik zu geben. Das mag bequem und in Ordnung sein, wenn man die Anzahl der Entwickler an einer Hand abzählen kann, ist aber eben ein Code-Merkmal, das zwischen den Zeilen steht und sich somit schlecht skalieren lässt.
Ich verstehe deinen Gedanken schon. Für gewöhnlich sind es aber genau diese Zweckentfremdungen, die einige Jahre im System überleben, dann aber irgendwann ein nicht mehr weiter aufschiebbares teures Refactoring nach sich ziehen (oder ein inkonsistentes, schwieriger wartbares Softwaresystem, das dann noch ein paar Jahre später ein noch teureres Refactoring erfordert).
Wenn man wirklich Werte strukturell unterscheiden will, ist eine Wrapper-Klasse eher das Mittel der Wahl und das ist auch, wie DSV üblicherweise umgesetzt wird. (Wie gesagt, alles aus dem Standpunkt, ein skalierbares, wartbares, Softwaresystem zu entwickeln. Beim Entwickeln eines kleinen Skripts nebenbei zum Rolladen steuern ist das natürlich way too much.)
Das mag bequem und in Ordnung sein, wenn man die Anzahl der Entwickler an einer Hand abzählen kann, ist aber eben ein Code-Merkmal, das zwischen den Zeilen steht und sich somit schlecht skalieren lässt.
Und genau für sowas gibt es Guidelines, die man im Team definieren sollte.
Die braucht man sowieso, um z.B. eine einheitliche Benennung zu erreichen.
Außerdem habe ich nie gesagt, dass man das immer machen sollte - wie so oft ist es eine Frage der Situation. Wenn man nun für jeden x-beliebigen Wert-Typ (Alter, Jahr, Name, what ever) einen eigenen Datentyp erfinden, dann gebe ich dir Recht: Chaos.
Es gibt aber eben auch Fälle (wie z.B. Brutto/Netto), wo das sehr sinnvoll ist, weil zum Einen eine Verwechslung kritisch sein kann und zum Anderen die beiden konkreten Werte in sich sehr ähnlich sind. Bei Brutto/Netto hat sich genau dieses Verfahren schon bewährt, auch über längere Zeit.
Wenn man wirklich Werte strukturell unterscheiden will, ist eine Wrapper-Klasse eher das Mittel der Wahl und das ist auch, wie DSV üblicherweise umgesetzt wird.
Exakt das ist es, was man mit den "Domain Specific Values" macht. Im Fall von C# würde ich dann aber Structs nehmen, spart den Overhead - vorausgesetzt, der Wert ist dafür geeignet.
Und genau für sowas gibt es Guidelines, die man im Team definieren sollte.
Aber doch nicht à "für Prozentwerte verwenden wir float" ;-) wie auch immer, ich denke, wir haben das ausreichend diskutiert. Ich persönlich würde das nicht zulassen - aber man muss ja auch nicht immer einer Meinung sein. Schönen Abend!
Doch, für Prozentwerte verwende ich float ^^
Aber da spricht mMn. nichts gegen, ist ein Datentyp wie jeder andere auch und besstens geeignet.
Der Grund, warum ich kein double nehme, ist einfach, dass es eben keine "normale" Zahl sondern ein Faktor ist - ein Unterschied, der sehr schwerwiegend sein kann.
Warum wird nicht einfach "DATE" verwendet? Integer ist doch quatsch
Bei Datenbanken gibt's aber noch den Speicherbedarf auf dem Datenträger.
Bei Massendaten kann das relevant werden, z.B. wenn man Messdaten von irgendwelchen Geräten sammelt, kommt vor, dass man die in Millionen-Schritten zählt :D
Oder der Typ ist eine Design-Entscheidung, z.B. um Fehler (Brutto vs. Netto) zu vermeiden, oder um auf etwas aufmerksam (bei mir ist Prozent immer float) zu machen.