| Author |
 Topic  |
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
 Posted - 29 March 2002 : 17:24:12
|
????
Um, forgive me for being ignorant, but isn't your conclusion a bit back to front.
in your large string tests, the db approach is significantly faster ?
plus, the oledb provider is much faster than an ODBC connection so using one would be LESS favourable for the string method
< |
 |
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 29 March 2002 : 17:27:28
|
forget my first comment, didn't notice the x1 and x100.
but second comment still stands, you really should avoid using the ODBC driver if you can. it adds an extra layer between you and the database.
< |
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 29 March 2002 : 17:32:08
|
I obviously need sleep, ignore both my posts, I completely mis read your post.
My reasons for preferring a db method are more related to multi language capabilites.
so, if using includes and strings, how do I allow users to have different languages ? or is it an all or nothing forum option.
allowing users to select their own language would be easy using a db method and would require no extra work.
< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 29 March 2002 : 17:36:01
|
quote:
The entire record set can be fetched into an array with a single call to getRows(), this is very quick and has been tested on access,MySQL and SQL. so would not be a great server hit.
In a way we need to reference these strings. If we don't want to implement a search routine for every string use from the ASP file, we need to refence them somehow: It can either be the array index, or it can be a "key" to be searched (or re-queried from the database). This is required because the calls in ASP files be hardcoded. If we cal them like:
response.write arrLang()
As we can have more than one languages on-line (user selectable from the selector), and we cannot use a multidimensional array, or multiple databases for technical/performance reasons, we need to keep such a database will have the following structure:
TABLE FORUM_LANGRESOURCES
INX INTEGER (PRIMARY INDEX) => to reach the string
LCID INTEGER (INDEX) => to
FILE TEXT (50) (INDEX)
ISDEF DEFAULT (INDEX)
PHRASE MEMO
And query it like:
SELECT ....
FROM LANG_RESOURCES
WHERE ((LCID= userLCID) AND ((FILE=currentfile) OR (ISDEF=1))
In any case, we need to get the include files' strings, because they are included here and there (indicated above as otherfiles - it can be through a field). ... or we will get the whole thing into an array.
There are also distribution problems, problems with translators, problems with maintaining (e.g. a user adding a new string because of a bug fix), etc - but more on these later.
I'm asking because I don't know: "which one is more speedy? Current include file approach or the database approach?"
quote:
admittedly these now need to be indexed, but they could easily be put in a dictionary object.
The dictionary object is not on every host. This was the reason that it is "forbidden" for me (ref: initial ideas given in the link above).
quote:
Surely using a db would mean that multilanguage was a much more viable proposition, since a user could choose his language and the query would select the relevant string, something you could not do using include files.
For sure! Perhaps only by using if-then-elseif.
quote:
Why would updates require the fso ?
update files could be written to insert strings using either the mod_setup prog (if they can use the fso) or I have an online tool which will read a dbs file and create you the correct asp script to update the db, so we could just provide those.
The second type of mod_setup (from v3.4) will do it fine, but the main problem again is the maintanability. In an ASP file, you just open the file (2000 lines) and edit it. About %30-%50 v3.3 of bug fixes caused new strings, old strings deleted, some strings modified. The same must be done in translations.
Think PinkPost v40b03 Patches< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 29 March 2002 : 17:42:39
|
quote:
I obviously need sleep, ignore both my posts, I completely mis read your post.
So do I (my head fell down). I'll compile some comments for the other question later.
Think PinkPost v40b03 Patches< |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 29 March 2002 : 17:46:20
|
quote:
I obviously need sleep, ignore both my posts, I completely mis read your post.
My reasons for preferring a db method are more related to multi language capabilites.
so, if using includes and strings, how do I allow users to have different languages ? or is it an all or nothing forum option.
allowing users to select their own language would be easy using a db method and would require no extra work.
Well I assume that you are not familiar with 4.0 beta?! It uses the langXXXX.asp files and it supports multi-language capabilities (or I may be misunderstanding the meaning of that - I assume that the user can choose the language for the forum strings). Also the DB will be less demanding of the server, memory wise, when talking about the multi-language support.
How important is this multi-language support? I don't know. I think it really depends on the person who answers it.
I think a DB offers extra functionality, but at the cost of performance. The ultimate choice depends on what you want to value the most. I have no easy answers for that.
Personally I want to have Snitz in my own language. That being the case, the messages will also be in portuguese. What would be the point of having portuguese content in a non-portuguese interface? I do admit that you can think differently on this. But I would also dare to guess that most Snitz user's are just like myself, although admiting that I may be wrong...
-------------------------------------------------
Installation Guide | Do's and Dont's | MODs< |
|
|
|
Nathan
Help Moderator
USA
7664 Posts |
Posted - 29 March 2002 : 17:50:58
|
quote:
TABLE FORUM_LANGRESOURCES INX INTEGER (PRIMARY INDEX) => to reach the string LCID INTEGER (INDEX) => to FILE TEXT (50) (INDEX) ISDEF DEFAULT (INDEX) PHRASE MEMO
And query it like:
SELECT .... FROM LANG_RESOURCES WHERE ((LCID= userLCID) AND ((FILE=currentfile) OR (ISDEF=1))
It would make so much more since for each language to have its own Field. Then you could SELECT 1033 AS STRING FROM WHERE ID = X
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's< |
|
|
|
Nathan
Help Moderator
USA
7664 Posts |
Posted - 29 March 2002 : 17:55:06
|
quote:
Personally I want to have Snitz in my own language. That being the case, the messages will also be in portuguese. What would be the point of having portuguese content in a non-portuguese interface? I do admit that you can think differently on this. But I would also dare to guess that most Snitz user's are just like myself, although admiting that I may be wrong...
Origionaly posted by bozden on April 21 2001
quote:
You can devide the forum categories into languages. Say if it is an international/multilanguage software, the support site can be devided into English, German, etc categories. Each user then gets in the desired subcategory, even if he/she does not understand text in the other categories.
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 29 March 2002 : 17:58:43
|
quote:
Ok. I did some testing, just to have a more concrete idea of what I was talking about.
Great! And thank you.
quote:
I did try 3 scripts:
Method 1. I changed lang2070.asp to include just the strings assignments and to have a timer to count the time to complete the script. As my first test showed very small timings, I created a for loop, so that the assignments are done 100 times.
Method 2. Using a table from one of my Access DBs I created a setup as described by Nathan. Read a recordset with two fields, an ID and a string, ordered from higher ID downto lower ID and created an array indexed by String_ID, using the exact process sugested by Nathan.
At the very beginning, I also did similar tests and get similar results. Because the testbed was not very well controlled I didn't rely on them to publish here.
I used:
A) 10 times execution, assigning the same string to variables in an include file (I didn't have any langNNNN file at that time)
B) Access 97 database with 1000 records (this was the number of strings in v3.0), and used Access 2000 connection string from the config.asp and used that 1000 strings 10 times in a loop (no getrows!!!).
* In both cases I did some simple string manipulation (assignments) inside the loop
* I used a W98 FE and (Celeron 466, 128 MB RAM) and used PWS.
The difference in results were too much (don't remember the numbers now, If you need them I'll try to find them from backups). I even could not measure case A (the screen refresh time was more than the execution time).
Think PinkPost v40b03 Patches< |
|
|
|
Nathan
Help Moderator
USA
7664 Posts |
Posted - 29 March 2002 : 18:07:55
|
There is somthing your not considering in your tests. That is, if you have 27 languages, the database time should not be affected much whereas the extra kbytes of include file is going to slow that method way down.
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's< |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 29 March 2002 : 18:08:43
|
quote:
You can devide the forum categories into languages. Say if it is an international/multilanguage software, the support site can be devided into English, German, etc categories. Each user then gets in the desired subcategory, even if he/she does not understand text in the other categories.
Well I think this is indeed a possibility. I would like to know, however, how many users have a single language forum (using 4.0) and how many have multi-language foruns. The include file method also allows multi-language support.
I won't go into an argument over this. Personally I would like to see what I think is the most frequent situation (single language forum) to be addressed with priority and with a solution that favors performance while offering some flexibility. I think the current solution strikes a reasonable deal, while favoring performance.
Performance is a recurring issue of discussion here. Any solution should take that into account.
-------------------------------------------------
Installation Guide | Do's and Dont's | MODs< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 29 March 2002 : 18:09:56
|
quote:
quote:
Personally I want to have Snitz in my own language. That being the case, the messages will also be in portuguese. What would be the point of having portuguese content in a non-portuguese interface? I do admit that you can think differently on this. But I would also dare to guess that most Snitz user's are just like myself, although admiting that I may be wrong...
Origionaly posted by bozden on April 21 2001
quote:
You can devide the forum categories into languages. Say if it is an international/multilanguage software, the support site can be devided into English, German, etc categories. Each user then gets in the desired subcategory, even if he/she does not understand text in the other categories.
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's
In addition to this:
* I like to use it in English (especially the admin part), although other (Turkish) people use it in Turkish
* You can extend the same idea to the whole site, and make the forum part of it using mods (slash, content manager, events etc) - like most of other institutions, our foundation also has international relations, and having an English counterpart is crutial.
* With the advent of v3.4, we will probably have the "group categories mod" already implemented. Each category group can show you another group of different language forums.
If you don't need it as "multiple simultaneous forums", the default will be your language (without the selector), and you will only need to install your language pack and run some admin pages for date-time, bad words, etc.
Think PinkPost v40b03 Patches< |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 29 March 2002 : 18:10:21
|
quote:
There is somthing your not considering in your tests. That is, if you have 27 languages, the database time should not be affected much whereas the extra kbytes of include file is going to slow that method way down.
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's
My question is simple: how many users, among the thousands of Snitz users, will need that?
-------------------------------------------------
Installation Guide | Do's and Dont's | MODs< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 29 March 2002 : 18:14:41
|
quote:
... if you have 27 languages ...
Oops. Two, or at most three. Do you like me to put some extra code to hinder this . Otherwise your host will be a bit angry with you.
Think PinkPost v40b03 Patches< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 29 March 2002 : 18:18:02
|
quote:
Performance is a recurring issue of discussion here. Any solution should take that into account.
So, flip back to page 1, post 1  .
Think PinkPost v40b03 Patches< |
|
|
|
Topic |
|
Forum Locked
