SQL to XML to XSLT to HTML, or SQL to HTML?

Currently in the system I work on, we seem to convert our SQL result sets into XML, then use XSLT to generate the final HTML. In most cases we never actually use the XML other than via the XSLT to create valid HTML.

Today I found myself looking at our code, thinking to myself "Why not skip some steps and开发者_StackOverflow中文版 go straight from SQL results to HTML?" Is there (from your experience/knowledge) any reason why our current approach should ever be done? To me it just seems like more work/files to keep track of.

Also, does anyone know which approach is technically more correct, and why that approach is the correct one? Or is this just a matter of preference? I attempted searching around here and on Google, and I have yet to find a convincing reason one way or the other. Please help me out!

---

Our system also uses Oracle XML+XSLT.

One scenario why this is good is when new requirements came. Our current reports must have the ability to be presented in CSV and Graph.

for CSV, its just a simple editing of the XSLT file without the need to change the structuring of SQL as XML. For the graph, all you need is to parse the XML, and that's it. we can also make our system a service which allows others systems to parse the xml to cater their needs.

Doing this approach indeed adds overhead to your system but gives you the ability to have an open-ended data representation. (i think, it's worth it)

---

if you use XML, you can change the XSLT at later time to use different presentation, not just HTML if you choose to go directly to HTML you might be saving some effort today but crippling the future upgradeability, if that is a word

---

One problem with simply writing a query that emits HTML is that "grouping" is an issue.

eg if you want to display all of the cities in each country and each country is to be in a heading tag, how do you write an SQL statement that identifies the change in country? This is difficult or impossible without a stored procedure with a cursor.

select CountryName, CityName
from Country, City
where CountryId = CityId

But given this grouping is not a problem for you, and you do not want to output in other formats and the HTML is not too complex and you do not expect the format of the HTML to change much then SQL to HTML direct is definitely a possibility. I would be very fast.

---

I don't believe there is a "technically more correct" version. It comes down to what we politely call "preference" but is usually more like prejudice, what they did "at my last job" and what makes the manager feel safe.

Also, remember the third option, pass them as JSON to a smart JS client that knows what to do with them. There are plenty of ways to do it. Plus all the other options.

But anyway, I myself prefer the SQL results -> HTML because I find it simpler. The SQL results come in native format and go directly to the destination format, no in-between steps that produce maintenance headaches.

Some would say that if this is done in code it's not that flexible, because you have to change code, but if you look at what is involved in changing XSLT and getting it right, I'd prefer to mess with the code.

QUICK EDIT: Remember as well that a change to the query (such as new fields) must be propagated through the base query, the conversion to XML, and the XSLT, on top of changing the design of the final layout. If you just go SQL->HTML you just change the query and the final step, again, no in-between steps.