Workarounds:
1. Use/convert language columns to TEXT fields instead of VARCHAR.
Disadvantages: Selects with ORDER BY or GROUP BY will force disk based
temporary tables. Thus reducing your shop performance by making the database
earlier disk bound then before.
2. Reduce size of your existing language columns to maximum of your used
data. Disadvantages: Newer data may not fit.
The first approach is already used in my case, but you will still hit
the limits at some time (in my case it does), because sadly there is
another limit per row by mysql, which is easily hit if you have too many
text fields. (the limit of 8000 bytes mentioned in your quote)
I investigated the case, and the only solution which doesn't hit any
limit is to "normalize" this part of the table.
> Taking out the language columns from oxarticle table into separate
> multiple tables. This is basically sharding the tables. In effect
> making unlimited number of languages possible. Shop will manage the
> multiple tables and select correct table based on language
> identifier. First possible version we can implement this is version
> 4.5.
Do you want to add one table per language or one table for all
languages? Anyway, my suggestion is to put everything in an single
oxarticles_i18n table, which contains the data for all languages, and
add an innodb foreign key relation to article and language. I think
generating 1 table per language can get a little bit chaotic to manage.
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
