If you have already started on a filesystem and if it does what you want it to do at a reasonable speed then stick with it :) .


Swapneel Dange wrote:
hey CHONG , PENG !

i think i have really given up the idea of putting up ORACKLE for my support. after all this discussion, i just think that there i sno urgent need for me to take up a HUMONGOUS taks of using ORACLE and i guess i will IMPLEMENT the SQLPLUS or the FILESYSTEM as my alternatives to the DATABASE application.

but in the end i would really like to know as to between SQLPLUS or FILESYSTEM, which will be convinient for me to HANDLE string stripping , string comparison and all that stuff ! ( BTW, i have really started implementing the FILESYSTEM to a good level )

do commment about this !

Swapneel Dange
505-642-4126
http://www.cs.nmsu.edu/~sdange








From: Chong Yu Meng <[EMAIL PROTECTED]>
Reply-To: "Tomcat Users List" <[EMAIL PROTECTED]>
To: Tomcat Users List <[EMAIL PROTECTED]>
Subject: Re: JDBC & ORACLE implementation !
Date: Tue, 25 Feb 2003 07:06:31 +0800

I think if you take Oracle installation, configuration and maintenance out of the picture, you definitely have a much more workable plan. I agree with Peter, in that designing the tables and application logic are going to be tough. I once wrote a servlet that processed CDR data from a Cisco switch, and I spent a lot of time getting the logic just right. If I understand you correctly, Swapneel, you need the database for storage only, correct ? Are you planning to use the Oracle text indexer, or are you implementing that yourself?

One last thing : JDBC may take you a shorter time to learn than the 2 weeks I put down in an earlier email. On reflection, that is probably padding too much, but I recommend that you do not underestimate the time taken to get the JDBC connection going, especially for Oracle. I've had problems with 8.1.5 before and had to resort to DataDirect drivers. 8.1.7 seems to be ok, though.

Regards,
chong


Peter Lin wrote:



overall, using JDBC with Tomcat is the easy part. Deciding how to implement your tables and application logic will be the hard part. If your data is not normalized and doesn't need to be, then the first thing you should look into is statistical analysis of text. there are several well tested algo's for doing this type of processing. Unfortunately I don't know the name of the algo's. I worked on integrating personalization applications a couple years back relating to filtering news.


If your needs aren't too complex, it shouldn't take too long to implement some form of statistical analysis. Using file system to store the entire text doesn't necessarily mean you can't store the text summaries in Oracle. Google for related topics and you should be to find some examples. If you're needs are more complex, you'll need to look into grammar based parsing, which is a slow process. Most of the comparison between grammar based and statistical parsing has shown that statistical is more effective. hope that helps.

peter

Swapneel Dange <[EMAIL PROTECTED]> wrote:hey peter, mike & chong !

so if i stay with a small thing like SQLPLUS, the JDBC connectivity wont be a tough thing to do as compared to the ORACLE implementation. right ? because in last few days after consulting with some people in-house here, i am thinking over the OPTION of SQLPLUS.

do commment on this !

Swapneel Dange
505-642-4126
http://www.cs.nmsu.edu/~sdange





--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail



--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]





--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to