hi,
for performance reasons that`s quite a bad idea! it`s too abstract.
and the most important fact: no possiblity to set special types of index!!!!
and of course it is more complex to do filtering using where clause.
This is completely true for the big tables and the things that get
queried quite often, but I don't agree on that for simple language data
which might still be stored in a single table - so there could be
some big and important i18n tables but there also should be a single
oxlang table that can store simple language data e.g. for small modules.
--
mit freundlichen Grüßen
Alexander Kludt
__________________________
Phone: 09283-5925453
Skype: kingschnulli
Email: [email protected]
Website: www.aggrosoft.de
__________________________
Aggrosoft it intelligence GbR
Tannstrasse 12
95111 Rehau
GERMANY
Sitz Rehau, Amtsgericht Hof
Steuernummer: 223/165/54508
Ust.-Id. Nr. gemäß § 27 a Umsatzsteuergesetz: DE260722773
___________________________
Diese Nachricht ist nur für den Empfänger () bestimmt, sollten
Sie nicht der Empfänger sein löschen Sie diese Nachricht
umgehend und geben Sie uns bitte per Email ([email protected]) Bescheid
über den fälschlichen Erhalt.
Sven Tietje schrieb:
hi,
I was waiting quite a long time for a proper solution of the language dependent
fields ... - an I am looking forward to the announced solution for OXID 4.5!!
:-)
+1 for a quick and clean solution.
I also think that a single table would be enough for keeping the lang stuff.
This table should have:
- OXID -> primary key
- OXOBJECTID -> ID of according dataset, e. g. OXID of an article
- OXFIELDNAME -> name of the table field, e. g. "OXTITLE"
- OXLANG -> language id
- OXVALUE -> content of field in fitting language
for performance reasons that`s quite a bad idea! it`s too abstract.
and the most important fact: no possiblity to set special types of index!!!!
and of course it is more complex to do filtering using where clause.
a i18n-table for each table containing language dependent data is a cleaner
solution (as christopher has proposed):
oxlanguages:
oxid
oxarticles:
oxid
price
oxarticles_i18n:
oxid
oxarticleid
oxlanguageid
title
text
By this you should be able to have as much languages as you wish and you could
store content from all sorts of tables in here. And it should be possible to
build a compatibility fallback for oxi18n class which first checks the new
table and if there is no entry there it could try the old logic. This will cost
a bit of performance but should anyway be a temporary solution.
But, building a new logic like mentioned above, you probably should also have a
proper oxlanguages table as well.
+1 for an oxlanguages table!
thanks
ps: if you really want a flexible solution, then store it in couchdb ;-)
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
