> Here are some ideas you might want to review these options: Other people have suggested variations of the below so I'll just respond here to cut down on the bandwidth. > 1. Try storing the data in the database as xml files them selves. You > then do not have to create the xml file. This will no doubt increase > your database size.
This, unfortunately, is not a possiblity because the databases get updated too frequently. Plus, I have 2 tables that have in excess of 80k records which also gets updated frequently. File I/O for updating a flat file DB would be atrocious. > 2. Store your xml templates in the database for faster retrieval. Please elaborate on this suggestion? > 3. Have the xml file reference the xslt file for the translation to > occur on the client end...they get the HTML and all u really worry about > is creating the xml file and having the xslt file. As far as I know, there are several issues with the various browsers processing and executing the XSL. There isn't full compliance, particularly with the actual commands (ie, xsl:copy, xsl:copy-of, etc) and/or if you want to manipulate the tree/DOM. Is this untrue? > 4. Do the translation of Database -> XML -> XSLT -> HTML all in PHP and > save the HTML output for caching. For the most part, this isn't feasible due to number 1 above. And for those files that I can cache, the data set being retrieved is so small that any performance hit (if any) would certainly be insignificant. So there wouldn't be much point in caching those. Even so, this does give me a few ideas and could possibly be the solution to a very different problem I need to address. Thank you all for your ideas and suggestions thus far. Please keep them coming if you haven't chimed in or if you think of anything else. I'm sure this information is helping other people as well! Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
