Rendering PDFs Natively in SQL

Question

Post reply

Rendering PDFs Natively in SQL

Viewing 4 posts - 31 through 33 (of 33 total)

You must be logged in to reply to this topic. Login to reply

Jeff Moden SSC Guru Points: 1000539 More actions · Answer 1

David Rueter (5/9/2013)

I'm always amazed at the number of people that blindly cry "scalability" as some sort of a trump card without understanding the requirements first. Scalability is only one of many factors--and it is not necessarily the most important. Not every application needs to be prepared for an infinite growth in usage. What is more, there are lots of ways to scale--even if the architect decides to centralize functionality in SQL.

Heh... While I agree that "infinite growth" is the wrong thing to plan for (because it's not possible), I'm always amazed at the number of people that have said things like you did only to turn around and ask why their queries (or someone else's queries) are so slow. People frequently use low counts to justify writing the damnedest code when writing it the right would have actually saved them time up front and will certainly save them time if scalability or other form of bullet-proofing changes. To wit, a good number of us don't blindly cry "scalability". We do it with good reasons to back it up.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
Intro to Tally Tables and Functions

icastellanos SSC Rookie Points: 44 More actions · Answer 2

Phil Parkin (5/9/2013)

David Rueter (5/9/2013)

@Phil: 🙂

Not to belabor the point... but "generation and display of graphic output" sounds like it applies to a PDF...as well as JPG, PNG, HTML, etc. "Rendering" is not format-specific.

In common usage, web developers talk about "rendering" web page output. Browsers have rendering engines. Sometimes developers even call the process of preparing server-side emitted HTML and Javascript as "rendering".

I'm sorry you object to the use of the word "rendering" to refer to combining textual + graphical elements and outputting them as a new graphical image...but I think I have used the word appropriately.

Not to nit-pick, but you say"...not to the generation of files". Nothing in this article has anything to do with files per-se...only a stream of "rendered" graphical data. (The sample test code does save this to a file for demonstration purposes, but otherwise files are not used.)

I'm not being testy, and this isn't a hill I'd want to die on...but I stand by my usage of the word.

Ah, me neither and I'm happy that you've been so constructive in your response. My sense of 'rendering' is that it must include the action of displaying - so, for example, a JPG is rendered only when it is displayed, not when it is created.

I'm going to have to go with Phil here. Rendering usually refers to the action of displaying something. PDF's are generated in your article.

That said, I think the technique you showed is quite valuable if one goes with eyes fully opened into it. Like with anything else, there are pros and cons, but this should definitely be one nice addition to the tool belt. Briefcasing it.