Feld-Inhalt soll größer werden

[dummzeuch]

Das kommt darauf an, ob der Kunde jedesmal zahlt, wenn er eine Datenbank-Änderung haben will.

Wenn ja, würde ich ihn nochmal explizit fragen, ob die neue Größe jetzt OK ist oder ob man vorsichtshalber etwas mehr nehmen sollte und wenn ja, wieviel (dabei auch auf die Nachteile hinweisen: Performance, Platzbedarf, bei mehrfacher Umstellung immer die Gefahr, dass dabei was schief geht). Das würde ich dann umsetzen. Wenn er später wieder kommt, ist das sein Problem.

Wenn nein, würde ich großzügig aufrunden, denn dann hast Du ja den Aufwand und der Kunde hat keinerlei Anreiz, sich vorher Gedanken zu machen.

[hoika]

Hallo,

Zitat:

Das kommt darauf an, ob der Kunde jedesmal zahlt, wenn er eine Datenbank-Änderung haben will.

Nein

Ich bleibe also bei meinem VarChar.

Zitat:

Platzbedarf

?

[DieDolly]

Um die Kosten und Arbeitszeit gering zu halten und trotzdem zum gewünschten Ergebnis zu kommen, würde ich das Limit auch einfach großzügig erhöhen.
Alles andere kostet die Firma zuviel Geld und dich zuviel Zeit zwecks Datenkonvertierungstool.

[hoika]

Hallo,
sehe ich auch so.

Datenkonvertierungstool. uiui, schöner Name
Das Konvertieren ist nicht so das Problem, aber das parallele Arbeiten der anderen Nutzer.

[Delphi.Narium]

Wenn ich mich nicht irre, belegt VarChar nur soviel, wie an Daten drinne ist.

Ein VarChar(1) mit einem Zeichen benötigt also in etwa genauso viel Platz, wie ein VarChar(4096) mit einem Zeichen.

Maximal geht halt VarChar(32765).

Aber Vorsicht: Ist auf dem Feld ein Index, dann muss man auch dashier Table 5.1. Maximum indexable (VAR)CHAR length beachten.

Von daher würd' ich entsprechend der Datenbankdefinition die Spalte einmalig vergrößern und zwar auf die Länge, die unter den gegebenen Umständen, maximal möglich / zulässig ist.

(Immer unter der Einschränkung: Hat's auch keine negativen Auswirkungen auf die Software?)

[TurboMagic]

Hm, vielleicht mal sicherheitshalber prüfen: ich meine mich aber zu erinnern,
dass Firebird VarChar Felder mit Länge > 250 Zeichen früher immer intern als Blob gespeichert hat.

Kann natürlich in neueren Versionen anders sein.

[hoika]

Hallo,
das wäre mir wirklich aber neu.
Weil der Standard früher (DBase, Paradox) war immer VarChar(255) für "lange" Felder. Das hatte ich dann auch bei neuen Feldern stellenweise übernommen.