The Daily WTF: Curious Perversions in Information Technology

TGV · 2009-09-14 Reply Admin

Hey guys, come on. Why defend storing queries in XML, which is stored in a file somewhere? Most database support some form of stored procedure, where, you know, you simply call the procedure called "delete_authorization" and you can keep everything in one neat little package? Plus you get better control over access rights with stored procedures than with XML (I can only begin to imagine the horrors of XML-based access lists linked to db user accounts).

lolwtf · 2009-09-14 Reply Admin

Anonymous:
SQL in XML CDATA.
Fire the programmer. WITH FIRE.

Here I was thinking they're better than I expected. They used CDATA instead of some horribly hacked-together system to build the query itself from a bunch of XML fields.

[post attempt 3]

2009-09-14 Reply Admin

MiffTheFox:
Essentially this is stored procedures for people who have no clue how to use stored procedures.

Or for people using a data base that does not provide stored procedures. Or for people who don't have a query editor that drops the QBE into their source code. Or for people who want to use the same query editor across apps in several languages. Or for people who re-use queries in multiple places in their app, perhaps by parameterizing parts of the query other than variables. Or for people so marginalized by the DBA that they can't add stored procedures to the data base.

There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy. --Hamlet 1:5, 166–167

-Harrow.

cconroy · 2009-09-14 Reply Admin

Bim Job:
campkev:
Good troll. Here's some chicken for you.
Don't be foolish. Trolls don't eat chicken.

I think he meant "chicken-fried human".

2009-09-14 Reply Admin

TGV:
Hey guys, come on. Why defend storing queries in XML, which is stored in a file somewhere? Most database support some form of stored procedure, where, you know, you simply call the procedure called "delete_authorization" and you can keep everything in one neat little package? Plus you get better control over access rights with stored procedures than with XML (I can only begin to imagine the horrors of XML-based access lists linked to db user accounts).

Well, customizing reports wouldn't work too well; if I were doing the sql in config thing, I'd use a separate user for that and limit its access to select only. I still prefer hardcoded sql when possible with column filters for customization.

2009-09-14 Reply Admin

Harrow:
MiffTheFox:
Essentially this is stored procedures for people who have no clue how to use stored procedures.
Or for people using a data base that does not provide stored procedures. Or for people who don't have a query editor that drops the QBE into their source code. Or for people who want to use the same query editor across apps in several languages. Or for people who re-use queries in multiple places in their app, perhaps by parameterizing parts of the query other than variables. Or for people so marginalized by the DBA that they can't add stored procedures to the data base.
There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy. --Hamlet 1:5, 166–167

-Harrow.

Or, you know, some places keep stored procs out of the DB as a matter of policy (at amazon, sprocs are used for things like updating the last updated by column). The idea is to keep all business logic in the app layer.

2009-09-14 Reply Admin

I cannot imagine why people are defending the deliberate avoidance of stored procedures. Would you all also defend the deliberate non use of functions and subroutines since you can technically write one giant set of code to handle everything? What about when things change? It is far easier to change 2 relevant stored procedures that are called in 40 different places than to track down 40 places with vaguely similar hard coded sql and update them all one at a time.

2009-09-14 Reply Admin

Brian White:
I cannot imagine why people are defending the deliberate avoidance of stored procedures. Would you all also defend the deliberate non use of functions and subroutines since you can technically write one giant set of code to handle everything? What about when things change? It is far easier to change 2 relevant stored procedures that are called in 40 different places than to track down 40 places with vaguely similar hard coded sql and update them all one at a time.

Not really. It's easier to manage one deployed module that has sql + app logic in it than coordinate the module change with a db change. My example with the hardcoded sql doesn't have to mean that sql is embedded all over the place - in java, stick your sql in a dto package and you have a fairly contained place to make changes.

galgorah · 2009-09-14 Reply Admin

psm321:
Anonymous:
SQL in XML CDATA.
Fire the programmer. WITH FIRE.
Off-topic, but I had to comment. I used to think that's what getting fired meant when I was little.

This isn't azeroth. You're boss isn't a dalaran mage who shoots a fireball at you when you get let go...

Lars Vargas · 2009-09-14 Reply Admin

The code snippet from the article translated into English:

Roses are red, Violets are blue. I'm schizophrenic, and so am I.

2009-09-14 Reply Admin

Brian White:
What about when things change? It is far easier to change 2 relevant stored procedures that are called in 40 different places than to track down 40 places with vaguely similar hard coded sql and update them all one at a time.

Playing devil's advocate again: And that's the beauty of softcoding it in an XML file, as already mentioned in the original article.

TGV · 2009-09-14 Reply Admin

Design Pattern:
Playing devil's advocate again: And that's the beauty of softcoding it in an XML file, as already mentioned in the original article.

The beauty of the XML file approach is of course that there are bound to be multiple copies all over the place. Everyone's test environment will have one, there will be copies for the dev server, for the test server, for production. People will end up with the wrong copy, errors will occur that nobody can reproduce, etc.

TGV · 2009-09-14 Reply Admin

Harrow:
Or for people using a data base that does not provide stored procedures. Or for people who don't have a query editor that drops the QBE into their source code. Or for people who want to use the same query editor across apps in several languages. Or for people who re-use queries in multiple places in their app, perhaps by parameterizing parts of the query other than variables. Or for people so marginalized by the DBA that they can't add stored procedures to the data base.

Ok, if you have to use MySql 0.9a, you're f*cked, that's for sure. Also if you have to run the db server on a Commodore 64. But come on, these people use XML (probably via a binding mechanism they don't understand), so what system could they use that doesn't support stored procedures?

The query editor doesn't make sense. There is no difference in writing a stored procedure compared to writing the SQL statement in an XML file.

The language argument also doesn't hold. What DB interface supports multiple languages and refuses stored procedures?

But a DBA from hell, that could very well be TRWTF.

2009-09-14 Reply Admin

elamberton:
DOA:
Now if only we could find the query to remove all the noise from the comments...

That would be: DELETE FROM Comments WHERE Content != 'Frist!'

FTFY

2009-09-14 Reply Admin

Jay Jay:
SB:
blindman:
PRMan:
Depending on the application, storing the SQL in an XML file may be a very wise idea.
Dude. WTF? That is a horrible idea.

Umm, its what the spring framework is based on. And tis rather popular.

Since when does popular = good idea?

Since IE

Oh wait...

Code Dependent · 2009-09-14 Reply Admin

TGV:
The beauty of the XML file approach is of course that there are bound to be multiple copies all over the place. Everyone's test environment will have one, there will be copies for the dev server, for the test server, for production. People will end up with the wrong copy, errors will occur that nobody can reproduce, etc.

Hence the value of using source control.

2009-09-14 Reply Admin

blindman:
PRMan:
The only WTF here is the copy and pasting and that the comments were not kept up to date.
Depending on the application, storing the SQL in an XML file may be a very wise idea.

For instance, different customers have different ideas of what columns they want to see in the "select record" preview table.

If you put the SQL in a config file, you can change it per customer and everyone is happy.
Dude. WTF? That is a horrible idea.

...It would be, if the original poster wasn't topcod3r!

2009-09-14 Reply Admin

It just looks like ZendFrameworks method of doing stuff to me (ie wrong)

TGV · 2009-09-14 Reply Admin

Code Dependent:
Hence the value of using source control.

That works well for bundles and monolithic apps, but for files that reside in different places, I wouldn't stake a lot on it. Nor on the app configuration in this case (the path to the XML file, that must be called, ah, here it is: _T(fileNotFound)).

SQL in XML gives you a lot of flexibility, but flexibility is powerful and therefore dangerous, as the OP already showed.

And how are you going to run procedures that require a bit more processing, e.g. with variables or loops or commits or whatever if your db cannot even handle stored procs?

Code Dependent · 2009-09-14 Reply Admin

TGV:
Code Dependent:
Hence the value of using source control.
That works well for bundles and monolithic apps, but for files that reside in different places, I wouldn't stake a lot on it. Nor on the app configuration in this case (the path to the XML file, that must be called, ah, here it is: _T(fileNotFound)).
SQL in XML gives you a lot of flexibility, but flexibility is powerful and therefore dangerous, as the OP already showed.

And how are you going to run procedures that require a bit more processing, e.g. with variables or loops or commits or whatever if your db cannot even handle stored procs?

I prefer to use ORM generation, myself. But since you were talking about multiple copies of a file and getting them confused, I mentioned source control. Used properly, source control doesn't permit the problems you mention, because everyone is updating to the lastest version for the environment they're working in.

Of course, you want to make sure your developers understand how to use source control. It's a tool, not an end in itself.

2009-09-14 Reply Admin

Dear Sir. On what planet are stored procedures more slow than embedded sql (with or without the extra xml-parsing layer)?

Truly yours /

2009-09-14 Reply Admin

Looks like a primitive implementation of an object-sql mapper (maybe without the object mapping part). See iBATIS for example.

The problem with this code is lack of development rigor (i.e. design/testing/etc.), not in the concept itself. It's not like you can't misname/miscomment a stored procedure, view or DAO.

Depending on exactly how this is used, perhaps there is a better architecture, but the main purpose: not hard coding SQL in the application is met in a useful way.

Coyne · 2009-09-14 Reply Admin

Actually this makes perfect sense.

It started out as a delete, but a requirement came in to insert a new row after doing the delete. So the programmer changed the delete to a select (rows no longer deleted require no replacement insert) and made the comment an "insert" to satisfy the requirements document. But changing the name would require modifying programs that reference the query so the name was left as "delete".

See? Perfect sense. XP

ChrisSamsDad · 2009-09-14 Reply Admin

Franz Kafka:

Not really. It's easier to manage one deployed module that has sql + app logic in it than coordinate the module change with a db change. My example with the hardcoded sql doesn't have to mean that sql is embedded all over the place - in java, stick your sql in a dto package and you have a fairly contained place to make changes.

Yeah those pesky databases, in fact, why bother with tables, store all the data in XML in the config files and never have to worry about tier mismatches again? Because as everyone knows, having a nice smooth release is the most important thing of all.

Oh no, wait, this is the real world! What about the several other systems that connect to the database: the ETL system for the data warehouse: The data dump from that supplier.

The best you can say for this is that at least it's a complete piece of SQL, I've seen so many systems where BITS of SQL were stored all over the place, pieced together from from HTTP request variable names, like this (from memory):

SQL = request(QryType) for each var in request.form if left(var,3) = "fld" then SQL = SQL + right(var,len(var)-3) + "," end if next SQL = left(SQL,len(SQL)-1) SQL = SQL + " FROM " + request("TlbName") ..... ad nauseum

I have a rule of thumb on system design: if you're doing some weird non-standard shit that goes against what 99.99% of the rest of the world are doing, you're either a visionary genius or there had really really better be a good reason.

There are very few visionary geniuses about, usually, it comes down to ignorance, stupidity or just not running it past someone with an actual brain.

Modular design: it's good for humans, cars, planes and computer systems.

2009-09-14 Reply Admin

Coyne:
See? Perfect sense. XP

Argh, brain explody!

2009-09-14 Reply Admin

ChrisSamsDad:
Franz Kafka:

Not really. It's easier to manage one deployed module that has sql + app logic in it than coordinate the module change with a db change. My example with the hardcoded sql doesn't have to mean that sql is embedded all over the place - in java, stick your sql in a dto package and you have a fairly contained place to make changes.

Yeah those pesky databases, in fact, why bother with tables, store all the data in XML in the config files and never have to worry about tier mismatches again? Because as everyone knows, having a nice smooth release is the most important thing of all.

Well, let's see:

your schema should change all that much
smooth releases mean mistakes are easier to recover because
easy release = potential for smaller releases

now, your DB and app both contain business logic, and this is just another way to divide up the thing. Keeping the sprocs to a minimum means that (for a price) you can roll forward or back a few revs with near impunity on a piece of code and reduce the dependencies on your group's changes.

In the case I'm thinking of, it wasn't that the DBAs were dicks - they were just overworked doing DBA things, so keeping the sprocs away matched up with the available labor pool. In practice, it worked pretty well.

Oh, and if you can help it, never let your internal schema depend on what a supplier decides to send over - that's asking for pain.

2009-09-14 Reply Admin

PRMan:
The only WTF here is the copy and pasting and that the comments were not kept up to date.
Depending on the application, storing the SQL in an XML file may be a very wise idea.

For instance, different customers have different ideas of what columns they want to see in the "select record" preview table.

If you put the SQL in a config file, you can change it per customer and everyone is happy.

You have a strange definition of happy. Then again, I'm rather allergic to XML. I have to wear gloves and safety glasses if I ever have to deal with it.

2009-09-14 Reply Admin

I know special cases are rare, but one special case is enough to knock any little bit of easy in a scheme using XML.

2009-09-14 Reply Admin

blindman:
PRMan:
The only WTF here is the copy and pasting and that the comments were not kept up to date.
Depending on the application, storing the SQL in an XML file may be a very wise idea.

For instance, different customers have different ideas of what columns they want to see in the "select record" preview table.

If you put the SQL in a config file, you can change it per customer and everyone is happy.
Dude. WTF? That is a horrible idea.

Will somebody explain exactly why this is such a horrible idea? Sure, we know that stored procs are one solution, but since when has been a crime to do something different?

If you respond with a variant of "stored procs are better" then you fail. I'm not asking anything about stored procs, I want to know why this is horrible.

2009-09-14 Reply Admin

Here are a few things : It is considered by many to keep the presentation independent of the data structure. Any filtering and formatting is done on the presentation layer. (this is in response to the 'columns they want to see' idea).

XML is always a bad choice.

It's a bad choice for editing simply because of the volume of text that it requires to describe simple things. Calling it human readable is stretching readable. If you are putting it in a nice GUI and it doesn't look like XML, well, its not xml at that layer.

It's a bad choice for data transmission because of its complexity. An xml node tries to be a list, associative array and a scalar values all at the same time, and has an associative array of attributes tagged to it as well. This doesn't even get into the complexity of XML namespace issues.

It is horrible for parsing. You have the DOM choice, which gobbles up RAM. You have the SAX choice, which because of the scalar/list/hash-ness of the xml node, is very complex. You can't say a node is done being parsed until its closing tag is encountered. If you are doing depth first, that can be a long long long way off. The only decent parsing model is the pull model, and you will miss any data you are not expecting in that one.

XML does not allow a magical 'ooo, everyone understands this' transmission of data. Both sides need to agree stringently on a schema. This is true for any sort of data protocol. The only thing XML gets you is that it can be validated. Then again, other data formats can be as well, so big whoop.

Eternal Density · 2009-09-14 Reply Admin

mel:
Shannon:
AlpineR:
char decrement( int &a )
{
    // Increment an integer
    a = ( a < 0 ? --a : a++ );
    return '*';
}
Oh man. That is beautiful :)
It is, I love it - maybe I should get it on a t-shirt or something. Made my day.

Okay http://www.zazzle.com.au/decremented_tshirt-235233485875495971

coyo · 2009-09-14 Reply Admin

Harrow:
MiffTheFox:
Essentially this is stored procedures for people who have no clue how to use stored procedures.
Or for people using a data base that does not provide stored procedures. Or for people who don't have a query editor that drops the QBE into their source code. Or for people who want to use the same query editor across apps in several languages. Or for people who re-use queries in multiple places in their app, perhaps by parameterizing parts of the query other than variables. Or for people so marginalized by the DBA that they can't add stored procedures to the data base.
There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy. --Hamlet 1:5, 166–167

-Harrow.

Maybe, but what do you think the odds are this is designed like that simply because XML is popular? If you just have skill with a hammer....

2009-09-14 Reply Admin

coyo:
XML does not allow a magical 'ooo, everyone understands this' transmission of data. Both sides need to agree stringently on a schema. This is true for any sort of data protocol. The only thing XML gets you is that it can be validated. Then again, other data formats can be as well, so big whoop.

XML is a decent interchange format because it's usually flexible enough to describe your data and it's fairly simple to make a data format and know that it'll work now and later after you add some fields (you can add fields to an xml stream and have it work, allowing noncoordinated format extensions).

XML is okay for a data storage format because it allows you to create a format and bung your data into it without much effort.

Basically, if space and cpu are less a concern than dev time (which is usually precious), XML works ok.

coyo · 2009-09-14 Reply Admin

Franz Kafka:
coyo:
XML does not allow a magical 'ooo, everyone understands this' transmission of data. Both sides need to agree stringently on a schema. This is true for any sort of data protocol. The only thing XML gets you is that it can be validated. Then again, other data formats can be as well, so big whoop.

XML is a decent interchange format because it's usually flexible enough to describe your data and it's fairly simple to make a data format and know that it'll work now and later after you add some fields (you can add fields to an xml stream and have it work, allowing noncoordinated format extensions).

Noncoordinated format extensions both sound kinda cool and a world of hurt. I would prefer a simple filter over such a beast. JSON is just as flexible - there is no data that XML can describe that JSON can not.

JSON can encapsulate the 3 common data containers - the scalar, the hash and the list - with complete ease. Translating back and forth between JSON data and a native data structure is very easy.

Franz Kafka:
XML is okay for a data storage format because it allows you to create a format and bung your data into it without much effort.

JSON is much better. Even YAML would be better. Even \n separated plain text is often preferable. Any of those require far less effort than XML does.

Franz Kafka:
Basically, if space and cpu are less a concern than dev time (which is usually precious), XML works ok.

I would rather go with a csv that starts with a clear descriptive header. That is much faster in dev time. Any example I have above is faster in dev time. If the development speed is due to particular tools, again, the presentation layer display something that transcends XML, be it hover over meta-data or a pretty dom tree.

Yes, I demonize XML but that doesn't mean its the worst or that its unworkable. Just about any programmer can look at it and understand it, and for me, that may be its greatest feature.

Thanks for the spirited defence of it.

2009-09-14 Reply Admin

[quote user="Franz Kafka"] Basically, if space and cpu are less a concern than dev time (which is usually precious), XML works ok.[/quote]

I would rather go with a csv that starts with a clear descriptive header. That is much faster in dev time. Any example I have above is faster in dev time. If the development speed is due to particular tools, again, the presentation layer display something that transcends XML, be it hover over meta-data or a pretty dom tree.

Yes, I demonize XML but that doesn't mean its the worst or that its unworkable. Just about any programmer can look at it and understand it, and for me, that may be its greatest feature.

Thanks for the spirited defence of it.[/quote]

Given the choice between csv and xml, I'd go with xml - it's standardized, so if 2 orgs can agree on a format, they can expect to read each others' stuff. csv is nonstandard and hacky (see how it deals with quotes and backslashes). Hell, even excel generates csv that it can't read. I'd much prefer a fairly verbose xml thing if the other side of the producer/consumer is in some other company.

2009-09-14 Reply Admin

Lars Vargas:
The code snippet from the article translated into English:
Roses are red, Violets are blue. I have multiple personality disorder, and so do I.

FTFY

2009-09-15 Reply Admin

And the wonderful iBatis SQL Mapper lets you factor out all your SQL into patterns kept in XML files. iBatis makes it wonderfully convenient to execute queries safely (no SQL injection attacks) and conveniently. You can even switch from one DBMS to another by supplying alternate sets of XML files.

2009-09-15 Reply Admin

wow:
trwtf is that the article was posted without a long meaningless backstory? cheers!

¡This cheese is burning me!

2009-09-15 Reply Admin

[quote user="Franz Kafka"][quote user="Franz Kafka"] Basically, if space and cpu are less a concern than dev time (which is usually precious), XML works ok.[/quote]

I would rather go with a csv that starts with a clear descriptive header. That is much faster in dev time. Any example I have above is faster in dev time. If the development speed is due to particular tools, again, the presentation layer display something that transcends XML, be it hover over meta-data or a pretty dom tree.

Yes, I demonize XML but that doesn't mean its the worst or that its unworkable. Just about any programmer can look at it and understand it, and for me, that may be its greatest feature.

Thanks for the spirited defence of it.[/quote]

Given the choice between csv and xml, I'd go with xml - it's standardized, so if 2 orgs can agree on a format, they can expect to read each others' stuff. csv is nonstandard and hacky (see how it deals with quotes and backslashes). Hell, even excel generates csv that it can't read. I'd much prefer a fairly verbose xml thing if the other side of the producer/consumer is in some other company.[/quote]

I didn't mean the horrible csv that Microsoft frankensteined, I mean a real cvs with a resonable escapes. Yes, the compaines have to agree on what the order and meanings of the columns are, but they would have to agree on an xml schema anyway. That agreement can be short, but can be glacial.

2009-09-15 Reply Admin

in early 2000 decoupling was the rage in software programming i too had fallen for it hook line and sinker. though not bad inherently, it does tend to confuse the average coders. also the code had so much overload that even though it was immensely flexible the users had a hard time getting it to run fast. and coders had a hard time debugging it in case configurations wouldn't suffice. database portability may have been in the developers mind..

2009-09-15 Reply Admin

PRMan:
If you put the SQL in a config file, you can change it per customer and everyone is happy.

This mean that's your SQL database design lack the abstract to manage per customer settings, please review it !

Anonymouse · 2009-09-15 Reply Admin

Aaron:
I wonder if they also abstracted the data access to the XML file itself? Surely they wouldn't want to hard-code all the xpaths.

The xpaths are of course stored in the DB...

2009-09-15 Reply Admin

nunca mas **const char:
Dear Sir. On what planet are stored procedures more slow than embedded sql (with or without the extra xml-parsing layer)?
Truly yours /

When the query plan isn't optimal for the arguments specified. When temp tables used inside stored procedures aren't optimised (they often aren't) and cause inefficient query plans internally. When the muppet who thought a string representing a date would work identically - when migrating to from in-line sql to a proc - to the correct date type of an indexed column that would result in an improved query plan. When statistics are stale and query plans are no longer optimal. I could go on, but my life is already foreshorted by database 'gurus' who don't understand even the most basic database internals.

2009-09-15 Reply Admin

TGV:
The beauty of the XML file approach is of course that there are bound to be multiple copies all over the place. Everyone's test environment will have one, there will be copies for the dev server, for the test server, for production. People will end up with the wrong copy, errors will occur that nobody can reproduce, etc.

Wait! According to you there is only one copy of the stored proc, so in your test environment you call stored procedures on the production database?

2009-09-15 Reply Admin

All this talk about XML is missing the point, XML is for storing and transmitting data and it's really very good at it when used appropriately.

You can fit all sorts of quite complex data in it and that's its strength.

This is essentially a string of text, there's no benefit whatsoever from storing it in an XML file, you might as well store it in text files, another database table, whatever. The point is the most appropriate place to store your SQL is the database itself, that's what it's for.

2009-09-15 Reply Admin

DaveK:
some guy:
TGV:
wow:
trwtf is that the article was posted without a long meaningless backstory? cheers!
On a dark, Tuesday morning, Jan Fabry entered his cubicle at Notech Inc. After all the problems of the morning, he hoped for a calm day. Then, at 10:05, an innocent ticket arrived in his mailbox. Quickly, Jan dived into the source code control system...
FTFY.

No no no, it goes like this...

On a dark, Tuesday morning, Jan Fabry entered his cubicle at Notech Inc. After all the problems of the morning, Jack hoped for a calm day. Then, at 10:05, an innocent ticket. Quickly, John dived into the source code control system...
TRWTF is the way you guys have him turning up in the morning, then hoping for a calm day after the morning, which appears to have passed instantaneously by, then suddenly winding the clock back to what most people would consider pretty much mid-morning.

And no, don't pretend you meant "... suddenly night fell and he was still there at 10:05pm". You're not fooling anybody!

TRWTF is that all daily WTF stories have these kind of continuity errors and you never noticed before.

dkf · 2009-09-15 Reply Admin

coyo:
JSON is just as flexible - there is no data that XML can describe that JSON can not.

Not quite. JSON gets messy when you start to want to mix different authorities for name-sets (XML namespaces are ugly and very irritating, but ''do'' work) and JSON has a very restricted set of basic scalar values, whereas XML is a bit better (assuming you're using the schema datatypes spec, which is very common).

In many ways, the main competitor for XML is ASN.1 because that also handles the multiple-naming-authorities problem. You probably don't want to write new things that use ASN.1 as a serialization format though as it is rather difficult to read without special support software. (CSV only works for simple tabular data, and implementations of it have some significant issues; it's best reserved as an if-all-else-fails interoperability format because of these things.)

ubersoldat · 2009-09-15 Reply Admin

SB:
blindman:
PRMan:
Depending on the application, storing the SQL in an XML file may be a very wise idea.
Dude. WTF? That is a horrible idea.

Umm, its what the spring framework is based on. And tis rather popular.

Very good example of a big WTF on its own. And BTW, it is, it's, its

2009-09-15 Reply Admin

AlpineR:

char decrement( int &a )
{
    // Increment an integer
    a = ( a < 0 ? --a : a++ );
    return '*';
}

This made me reach for the upvote link. Alas there was none.

It's not the first time I wanted to upvote a comment here :)

2009-09-15 Reply Admin

xtremezone:
Though there are these things called stored procedures that sort of separate the data access from the application code already. Albeit, they're generally a little bit more slow and difficult to maintain, which can be a double-edged sword.

Stored Procedures are slower than ad-hoc queries extracted from an XML-file???????? Where does this idiot come from?

DELETE. No, INSERT! No, SELECT!

Leave a comment on “DELETE. No, INSERT! No, SELECT! ”