Danke für den Link. Dass TEXT deprecated ist, ist einerseits natürlich 'ne wichtige Info, andererseits macht es mir auch die Entscheidung leichter. Ich nehme dann VARCHAR(max), dann sind die kurzen und langen Stringfelder wenigstens auch vom grundlegend selben Datentyp, und hoffe, dass die generierten Inhalte da auch wirklich alle reinpassen. Wenn das aktuell wirklich 2 GB sind statt 65'000 Zeichen, ist das definitiv kein Problem. Wobei ich realisitisch auch eigentlich erwarte, dass die Inhalte für diesen Feldtypen niemals 65'000 Zeichen überschreiten, das wären knapp 100 vollgeschriebene DIN A4 Seiten, und soviel gibt der Benutzer niemals für unseren Verwendungszweck ein.
> Wenn etwas irrelevant ist, dann hat es in einer
DB nichts zu suchen! Diese Gedanken sollte man sich aber machen bevor man die
DB definiert.
Sorry, das war falsch formuliert. Zwar ist es durchaus pro Zeile ein rein optionales Feld, dennoch wird es im Programm (und somit auch der Datenbank) gebraucht. Das "irrelevant" bezog sich ausschließlich auf das hier genannte NULL <--> "" Problem
https://www.delphipraxis.net/204363-...oder-null.html bei Abfragen ("Zeige alle Datensätze, deren Feld nicht leer oder NULL ist"), da das "MeinText"-Feld niemals Filterkriterium ist. Das Feld wird zwar bei
allen betroffenen Zeilen der SELECT Abfrage ausgelesen, um die -optional- gespeicherten Werte zu verarbeiten - ob da jetzt aber NULL, "" oder ein Wert drinnen steht, ist als solches egal: bei NULL oder "" werden die Standardwerte (vom Programm, nicht vom
SQL-Server) verwendet.
Mir ging es ursächlich darum, eben in diesem neuen Datenbanksystem
global das Dilemma mit NULL <--> "" bei Abfragen vermeiden zu können, indem ich die Datenbank entsprechend designe. Dass es einem jetzt von der anderen Seite ("Beim Schreiben WERDEN leere Text == NULL) wieder um die Ohren fliegt, ist schier zum kotzen.
Die Verwendung von VARCHAR(MAX) sollte dann aber hoffentlich wirklich BEIDE Probleme lösen: durch DEFAULT '' sollte ist es bis jetzt scheinbar egal, wenn leere nicht-null Strings in die Datenbank gespeichert werden, bzw. das Feld gar nicht gesetzt wird; es greift ja dann der Standardwert. Und auch die Abfragen in den anderen Tabellen, wo ich dann wieder sage: SELECT * FROM Bla WHERE TemplateName <> ""; sollten garantiert fehlerfrei laufen, da ich hier NULL-Werte nicht berücksichtigen muss, da es keine geben kann. Richtig so?
Ich denke/hoffe das Problem gilt damit als gelöst. Vielen Dank!
Edit:
@Delphi.Narium
Danke für den Beitrag. Ohne die Diskussion jetzt über (Un-)Sinn von "NOT NULL" führen zu wollen, geht es mir eigentlich darum, dass ich ja
definitiv einen Standardwert in der Datenbank für dieses Feld gesetzt habe (leerer String "", nicht NULL!), und über _Target.FieldByName(MeinText).AsString := ''; ja auch einen GÜLTIGEN leeren String (nicht: NULL bzw. in Delphi NIL!) übergebe, und Dieser dann
fälschlicherweise von der Drittanbieter-Komponente oder dem Server intern umgewandelt wird zu NULL, was imo nicht sein darf.
Delphi 10.4 32-Bit auf Windows 10 Pro 64-Bit, ehem. Delphi 2010 32-Bit auf Windows 10 Pro 64-Bit