mich würde es brennend interessieren, ob was gegen eine Änderung eines Datentyps spricht?
In meinem speziellen Fall würde ich den Datentyp von OXVALUE aus der Tabelle oxobject2attribute, von CHAR(255) auf TEXT, ändern.
Ich frage mich sowieso, warum man bei Attributen eine Beschränkung auf 255 Zeichen haben sollte.
Ich würde mich über eure Meinungen/Erfahrungen bzw. Pro/Kontras freuen.
mich würde es brennend interessieren, ob was gegen eine Änderung eines Datentyps spricht?
In meinem speziellen Fall würde ich den Datentyp von OXVALUE aus der Tabelle oxobject2attribute, von CHAR(255) auf TEXT, ändern.
Ich frage mich sowieso, warum man bei Attributen eine Beschränkung auf 255 Zeichen haben sollte.
Ich würde mich über eure Meinungen/Erfahrungen bzw. Pro/Kontras freuen.
Vielen Dank & Grüße
Ertanos[/QUOTE]
Hi,
ich bin kein SQL-Experte, würde aber auf Performance und Datenbankgröße schließen. Hast du es in ner Testumgebung einfach mal ausprobiert?
Was hast du denn vor, dort als Roman rein zu schreiben? Ist es evtl. eleganter, dass in ein Content-Element umzuwandeln (weil komfortabler zu füllen) und zu verlinken?
danke für deine Antwort und kleine Entwarnung, es wird kein Roman
Das Attribut OXVALUE wird über ein WWS mit Konfektionsgrößenangaben befüllt und die sind etwas länger als die vorgesehenen bzw. verfügbaren 255 Zeichen.
Die Umstellung von dem Datentyp von CHAR auf TEXT hatte tadellos funktioniert, darin hatte ich auch kein Problem gesehen.
Es wundert mich halt, warum diese Voreinstellung (CHAR für Attribute) gewählt wurde.
Meines Erachtens sollten Attribute nicht limitiert sein, da man ja die Attribute als Erweiterungen von nicht vorhandenen Elementen nutzen kann, um einen Artikel wunschgemäß im Shop abzubilden bzw. darzustellen.
…dein Lösungsansatz mit den Content-Elementen würde mich aber dennoch interessieren. Wie stellst du dir sowas vor? …ein kleines Beispiel wäre nett
P.S.: Ist es evtl. besser den Datentyp wegen der Updates nicht zu verändern?
Genau genommen braucht natürlich jede leere Column und jedes überdimensionierte Feld Ressourcen - alles gleich überdimensioieren wäre ja auch nicht sinnvoll. Also gibt Oxid einen Standard vor, den Du in diesem Fall problemlos ändern kannst oder musst.
Wenn das Attribut über ein WWS mit Konfektionsgrößenangaben befüllt wird und die Schnittstelle dazu bereits programmiert ist, dann mach es so wie Du es brauchst und ein Upgrade ist auch kein Problem - im “worst case” könntest Du es ja wieder ändern und aus dem WWS neu befüllen.
Alternative Lösungen, wie Josha schon sagt, können evtl. Vorteile im Handking bieten - das kann ich aber ohne Dein System zu kennen nicht beurteilen.