RE: Searching Problem

7 views
Skip to first unread message

sudhakar....@accenture.com

unread,
Aug 21, 2007, 5:26:06 AM8/21/07
to rajeshs...@gmail.com, kalyan-prabu...@hp.com, dm_gdm_mu...@googlegroups.com
Hi Rajesh,

Tell us the following factors

1. How do you folks do the search in Documentum? is it thru web clients like Webtop? then, would there be any option to make your search based on Registered Tables in Webtop Advanced Search?

2. Look out your table structure (the Registered Table that you mentioned below, the poorest table design i can say) which has got one column for storing String, Datetime, Integer, Float etc. this coulum would make your search process go dead if you make your search based on this. Just imagine if i want to list out objects which should belong to say 1/1/2006 to 1/1/2007, then your search process will not be able to perform with less throughput time.
So will you be able to make more molumns for the Registered Table to split your data across columns for a object

3. The Search engine sitting in your repository, is it FAST, Verity or something else. i could suggest the strong players in search would be in the following order.
--> Autonomy
--> FAST and Verity
--> Google (no support for dctm)

- Sudhakar Kanakaraj
+91 98843 02880.

________________________________

From: rajesh shivekar [mailto:rajeshs...@gmail.com]
Sent: Tue 8/21/2007 2:02 PM
To: Kanagasabai, Kalyan Prabu; Kanakaraj, Sudhakar
Subject: Searching Problem


Sudhakar/Kalyan,

In one of our project the data is huge around 5 TB. 500GB/day.
so the speed of search will be very slow.

what should we do?

* One way we can reduce the volume is by indexing only the metadata and not the actual full text of reports. This will reduce the total volume up to the range of ~40Gb.
* Secondly, if we have a custom object type, while indexing, can we also include the contents of a foreign table (related with a Foreign Key like r_object_id) as the contents of the object. One example of this situation is if we create an object type called reports and a registered table like indexed_info. the relationship is like this given below. Can we customize full text indexing so that when it indexes the object 9D293AD3B018CD16, it also indexes the three rows from the registered table Index_info that are having the foreign key relationship.

Custom object type - Report

R_object_id

Object_name

Title

Load_date

Source

9D293AD3B018CD16

Report_1

Report Title

1-Jan-07

Internal

Registered Table - Index_info

Object_ID (Foreign Key)
Property_Name
Property_Value
9D293AD3B018CD16
Account_Name
Apple Computers
9D293AD3B018CD16
Account_Type
Venture Capitalist
9D293AD3B018CD16
Account_ID
621475
9D293AD3B018CA22
Account_ID
148528
9D293AD3B018CA22
Account_Volume
100000000.00
9D293AD3B018CA22
Open_Date
1/1/1999


which way is feasible?
If you have any other idea please tell.


This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

sudhakar....@accenture.com

unread,
Aug 21, 2007, 7:05:01 AM8/21/07
to rajeshs...@gmail.com, dm_gdm_mu...@googlegroups.com
HI Rajesh,

--> if its webtop, make sure you will be able to make search based on Reistered Tables, otherwise you got to face customizing webtop search.

--> Try to avoid Registered Tables and make your table columns as Meta-Data to your custom doctypes. This makes your cache folders carry the Meta-Data values and makes Indexing easier with DQL scripts.

--> Even if you still want to go for Registered Tables, make your Registered Table have columns for different data types (String, Float, Integer, Datetime) not like you mentioned below.

- Sudhakar Kanakaraj.
+ 91 98843 02880

________________________________

From: rajesh shivekar [mailto:rajeshs...@gmail.com]

Sent: Tue 8/21/2007 3:16 PM
To: Kanakaraj, Sudhakar
Subject: Re: Searching Problem


Answers for your questions.

1. It will be web client only.
But I am not sure whether it will be WebTop.
2. Table design is not yet finilized, It is just a example
3. We are using FAST Search OEM Fast search.

-Rajesh

Hi Rajesh,

Tell us the following factors

1. How do you folks do the search in Documentum? is it thru web clients like Webtop? then, would there be any option to make your search based on Registered Tables in Webtop Advanced Search?

2. Look out your table structure (the Registered Table that you mentioned below, the poorest table design i can say) which has got one column for storing String, Datetime, Integer, Float etc. this coulum would make your search process go dead if you make your search based on this. Just imagine if i want to list out objects which should belong to say 1/1/2006 to 1/1/2007, then your search process will not be able to perform with less throughput time.
So will you be able to make more molumns for the Registered Table to split your data across columns for a object

3. The Search engine sitting in your repository, is it FAST, Verity or something else. i could suggest the strong players in search would be in the following order.
--> Autonomy
--> FAST and Verity
--> Google (no support for dctm)

- Sudhakar Kanakaraj
+91 98843 02880.


________________________________

Reply all
Reply to author
Forward
0 new messages