Re: Once every 7 years a post of monumental stupidity comes along ...

Hi There, Am 23.09.2009 um 14:37 schrieb Joshua Hutchinson:
Keith,
While I agree that Marcello's diplomacy is terrible (always has been, doubt that's going to change! :) ... he's right and you're wrong.
He never claimed the DB has to reindex and he presented very real reasons why your solution is terrible from an efficiency point of view.
Biggest problem (summary): Your solution does the work on the web server, his solution does it on the DB server.
Josh
In my original post I NEVER said where this code could be used whether on the web server or DB server. Furthermore, I mentioned that the standard sort routines used in a DB server can be overiden and the supoopsed code can be used. So, the question of efficiency is mute. My solution will work anywhere you want it to. Another reason the the socalled efficency arguement is mute is that the web-server is calling the db-server that is actually doing all the work. As for Marcello attitude I personally could care less. All I wanted to do is help and pointed to a simple fact that the sort routine for the data is easy enough to implement. It is not always good enough to use just built-ins. Which I assume is the case. The matter of fact remains that the proper sorting can be easily achieved anywhere in the system with out any overhead. Position it where you want. I have programmed just such a situation and had no overhead. the database that was acessed via a web-server was set so that no new sorting or indexing was required when the db was called. I do know what I am doing an what can be done.

Keith J. Schultz wrote:
In my original post I NEVER said where this code could be used whether on the web server or DB server.
If you intended your code to be run on the database server, it would be an even more incredibly stupid thing to do. If you want to influence the database server, then you must not write a routine that *compares* strings, but a routine that *transforms* strings: If you wanted to sort like German phonebooks do, that is: to sort 'ö' as 'oe', then you would write a routine that substitutes all 'ö's in your input with 'oe's. Then you would feed the transformed string to the index table while feeding the original string to the data table. Voilà. Of course you would have to transform all search terms in the same fashion too, because databases do most of the work on index tables and reach out to the data tables only when they really really really need to.
Furthermore, I mentioned that the standard sort routines used in a DB server can be overiden and the supoopsed code can be used.
How would you know? You don't even know which database we are using.
My solution will work anywhere you want it to.
Your `solution´ didn't even work on paper. I found 3 fat bugs just on a first eyeball revue.
I have programmed just such a situation and had no overhead. the database that was acessed via a web-server was set so that no new sorting or indexing was required when the db was called.
You programmed a small in-house application that gets hit a dozen times a day. In your situation you can get away with any amount of programming sloppiness because the hardware is so much superior to the task. I am running a site that gets more than 1 Megahits a day, serving more than 70,000 customers per day. Failure to consider scalability issues is another telltale sign of the rookie. -- Marcello Perathoner webmaster@gutenberg.org

Hi Marcello, As you evidently do not know even the slightest about dbase systems I will stop responding to your arguments. I will repeat I was using pseudo-code so you could use what ever is approriate for the task. The basic algorithm wil work with any kind of data or structures for that matter. All that is need is an appropriate cardnal function. You have fail to realize this. Also, I do not what kind of server system you are using, but I have known system that can handle "ö" for decades. Like I said you are not evidently qualified to partake in this discussion. regards Keith. Am 24.09.2009 um 13:00 schrieb Marcello Perathoner:
Keith J. Schultz wrote:
In my original post I NEVER said where this code could be used whether on the web server or DB server.
If you intended your code to be run on the database server, it would be an even more incredibly stupid thing to do.
If you want to influence the database server, then you must not write a routine that *compares* strings, but a routine that *transforms* strings:
If you wanted to sort like German phonebooks do, that is: to sort 'ö' as 'oe', then you would write a routine that substitutes all 'ö's in your input with 'oe's. Then you would feed the transformed string to the index table while feeding the original string to the data table. Voilà.
Of course you would have to transform all search terms in the same fashion too, because databases do most of the work on index tables and reach out to the data tables only when they really really really need to.
Furthermore, I mentioned that the standard sort routines used in a DB server can be overiden and the supoopsed code can be used.
How would you know? You don't even know which database we are using.
My solution will work anywhere you want it to.
Your `solution´ didn't even work on paper. I found 3 fat bugs just on a first eyeball revue.
I have programmed just such a situation and had no overhead. the database that was acessed via a web-server was set so that no new sorting or indexing was required when the db was called.
You programmed a small in-house application that gets hit a dozen times a day. In your situation you can get away with any amount of programming sloppiness because the hardware is so much superior to the task.
I am running a site that gets more than 1 Megahits a day, serving more than 70,000 customers per day.
Failure to consider scalability issues is another telltale sign of the rookie.
-- Marcello Perathoner webmaster@gutenberg.org _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

Hi Marcello, just you more after thought. I assume you have a database. If so just add another or more field for sorting and adjust the information from other fields. this is a one time trip and you have the sorting that you need, just use sort by functions. Of course I am assuming that your database is structured. regards Keith. Am 24.09.2009 um 13:00 schrieb Marcello Perathoner:
Keith J. Schultz wrote:
In my original post I NEVER said where this code could be used whether on the web server or DB server.
If you intended your code to be run on the database server, it would be an even more incredibly stupid thing to do.
If you want to influence the database server, then you must not write a routine that *compares* strings, but a routine that *transforms* strings:
If you wanted to sort like German phonebooks do, that is: to sort 'ö' as 'oe', then you would write a routine that substitutes all 'ö's in your input with 'oe's. Then you would feed the transformed string to the index table while feeding the original string to the data table. Voilà.
Of course you would have to transform all search terms in the same fashion too, because databases do most of the work on index tables and reach out to the data tables only when they really really really need to.
Furthermore, I mentioned that the standard sort routines used in a DB server can be overiden and the supoopsed code can be used.
How would you know? You don't even know which database we are using.
My solution will work anywhere you want it to.
Your `solution´ didn't even work on paper. I found 3 fat bugs just on a first eyeball revue.
I have programmed just such a situation and had no overhead. the database that was acessed via a web-server was set so that no new sorting or indexing was required when the db was called.
You programmed a small in-house application that gets hit a dozen times a day. In your situation you can get away with any amount of programming sloppiness because the hardware is so much superior to the task.
I am running a site that gets more than 1 Megahits a day, serving more than 70,000 customers per day.
Failure to consider scalability issues is another telltale sign of the rookie.
-- Marcello Perathoner webmaster@gutenberg.org _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
participants (3)
-
Joshua Hutchinson
-
Keith J. Schultz
-
Marcello Perathoner