it all depends on your application. we have had the same problem and used a strategy that is somehow a little bit of both approaches. we use a foreign key and a table containing a text id and a long column for the actual texts. for searches we have a separate table that is used for indexing/searching that chunks the searchable data in 8K portions. one could say we have hacked something like a full-text search engine (very primitive and specific to the application we are developing for our customer) but so far it works OK since the amounts of searchable data small enough to use a simple like '%searchstring%' type of search. trade-off in this is you have to keep the index up-to-date but on the other hand it's rather flexible (we took a document-oriented approach such as in the lucene API) so making something else in the application searchable does not require much effort.
we had used lucene for indexing before, which is really fast but we had some strange errors and limitations (no substring search possible) we found hard to cope with. it would be great to have at least a primitive full text search in sapdb but so far it looks as if this is not coming in the near future. just my 2c, regards, robert On Monday 07 October 2002 13:57, Mario Oberrauch wrote: > Hi, > > as far as i know the maximum row-size is limited to 8k. > Now we have a case that there can be a lot more of data than this (in > plain text - no binary data). I think we will not get a single field > that is larger than that. We could use Long's but LIKE-querys are in use > so they fall apart. > > Our methods of resolution upto now: > - make bolb's > - save all texts in seperate table and assign foreign key > > Is there a better way to solute? If not, which one of the two named is > to be prefered? (mine is defenitly number two) > > Thanks, > Mario _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
