Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DB: Feld "value" in Type "text" ändern #5

Open
HenryVolkmer opened this issue Mar 30, 2014 · 8 comments
Open

DB: Feld "value" in Type "text" ändern #5

HenryVolkmer opened this issue Mar 30, 2014 · 8 comments
Milestone

Comments

@HenryVolkmer
Copy link

Ich schlage vor, das Feld "value" von "varchar(255)" in "text" zu ändern.

@andreasisaak
Copy link
Contributor

@discordier Gehen hier bei Contao eventuell Daten verloren?

@discordier
Copy link
Member

Sollte keine Probleme machen, jedoch muss man dann einen upgrade step bauen, welcher bestehende Installationen dann auch aendert. Ansonsten bleiben die weiterhin auf varchar und nur neue Attribute kommen in den Genuss der laengeren column.

Allgemein ist jedoch die Frage, ob bei einer solchen Laenge nicht das Attribut "longtext" dem use case eher entspricht, denn 255 Zeichen in einem Text input sind schon kaum lesbar, dann doch eher eine textarea und somit longtext, oder nicht?

@andreasisaak
Copy link
Contributor

Ja wäre eine sinnvolle Optimierung. Wenn dann gleich richtig.

@zonky2
Copy link
Contributor

zonky2 commented Dec 16, 2016

bisher habe ich keine Infos erhalten, dass die 255 Zeichen nicht ausreichen würden - solange kein "dringender" Handlungsbedarf besteht, würde ich die Tabelle erstmal "schmal" halten...

Edit: 255 Zeichen sind es ja nur bei "pure ACSII" bei UTF8 sind ja schon drei Byte je Zeichen

@zonky2 zonky2 added this to the Future milestone Dec 16, 2016
@HenryVolkmer
Copy link
Author

welche Nachteile ergeben sich denn?

@zonky2 zonky2 modified the milestones: 2.1.0, Future Jan 12, 2017
@discordier
Copy link
Member

TEXT and BLOB is stored off the table with the table just having a pointer to the location of the actual storage where VARCHAR is stored inline with the table.
VARCHAR is usually faster IF the data is frequently retrieved (included by most queries) which is the case here.
If we would not retrieve the data often, TEXT would come in handy but that would render the external table simply a "lookup map" of values. MySQL would have to retrieve all matching rows from the table and later on then the TEXT values from the TEXT file.
I fear we will have a speed impact here.

@cliffparnitzky
Copy link

I think increasing the number of the varchar to e.g. 500 is enough. As @discordier mentioned here #5 (comment) the user has to choose the longtext field with the textarea when there is a lot of text.

@discordier
Copy link
Member

I'd bump this to 2.1 then unless someone is eager to implement it (including the database updater).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants