Greg, Assuming the application that pushes the denormalized field can be changed, then you should be able to do a one-time query that extracts the information into a normalized table using SQL. I don't remember exact formula off hand, but it was an odd combination of SQL instr and substr functions. I'm sure it's out there on some SQL techniques site.
If the said application remains the same, then I would be tempted to explore the use of triggers, stored procedures, and relational integrity to patch the problem. If the server you're using doesn't have that capability, then some cron job could kick off the query, but SQL would be fastest. Phillip. --- Greg Nudelman <[EMAIL PROTECTED]> wrote: > Nothing. Except I have to do 45000 of these... and the data is quite > dirty > as I metioned, and I am in no hurry to try and clean it up... and > write the > validation/cleanup routine for the new data... You can say I am > somewhat > lazy. hehehehe > > I think of all the Java String operations I've tested, indexOf is > nether the > slowest, nor the fastest, clocking in at 15 miliseconds. To > contrast, > String.equalsIgnoreCase is a hog, at 28 miliseconds, and > String.equals is an > acceptable 7 miliseconds, which is still far away from the coveted > int == > int is only 3 miliseconds. (on my test strings, your results will > vary). > > However, I wanted to make sure I don't miss something more obvious. > For > example, SQL LIKE is a great idea, however, my DB data structure may > unfortunately prevent me from doing this (I have to think some more, > maybe I > can use it). I also like the HashTable lookup idea, but > java.util.StringTokenizer is so unbelivably slow, that I will have to > write > one of my own if I am to implement this method. And those perl > utilities are > priceless!! > > Great ideas, everyone, Thank you so much!!! > > Greg --- You are currently subscribed to jdjlist as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] http://www.sys-con.com/fusetalk
