Feld-Inhalt soll größer werden

[hoika]

Hallo,
ich habe ein Datenbank-Feld mit VarChar(200), die Länge kommt von einer Kundenanforderung.
Jetzt möchte der Kunde wieder Erwarten (... ) 300 Zeichen speichern.

Was würdet ihr da machen:
1. Feld verlängern auf 300 Zeichen und auf die nächste Längenanpassungs-Anforderung warten
2. aus dem VarChar ein Blob machen mit einer einmaligen Konvertierung.

Punkt 2 für mich ist etwas problematischer, weil idR DB-Updates im laufenden Betrieb erfolgen sollen
(also keine "Wartungsintervalle"), ob das jetzt Sinn macht oder nicht ...

[mkinzler]

Punkt 2 nur wenn erwartet ist, dass die Feldlänge jenseits der 32K wachsen wird.

[DieDolly]

Das steht zwar nicht zur Debatte aber ich würde das Feld großzügig erst einmnal auf 1000 erhöhen.
Dann hat der Kunde erstmal Ruhe und es muss nichts konvertiert werden. Dein Arbeitsaufwand hält sich dann auch in Grenzen.

Wenn der Kunde bis jetzt mit 200 auskam jetzt aber 300 braucht, wird er die 1000 vielleicht erst in ein paar Jahren brauchen wenn überhaupt.

[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.