Database - BLOB fields vs. scalability?

Hello

I'm working on a project at the moment, which I'm trying to design to be as scalable as possible. It isn't huge (code-wise), however it will be quite database intensive...

I have a few questions...

BLOB fields- one part of the application requires a picture to sometimes be stored in the record.... now, an OLE (BLOB) field has been the easiest way to do this so far... that way, i can easily tell if a picture is associated to a record.... my main concern was that if i stored images in a folder on the server, rather than in the database itself, that i would get too many conflicts with filenames... lets be realistic.... having thousands of picture files, there's bound to be duplicate filenames.... also, another problem here, is the user can often change/delete the picture from the record... then i am left with unused pictures, which can add up ....

what i'd like to know, is, is BLOB really that much of a hinderance on the database's performance? these images aren't huge (maybe 30 kb average size or so)...

Another thing, does anybody have any good reading materials on Index's ? i need to know where to put index's...

Yet another topic is keyword searching... the most heavily accessed page on the site will be a keyword searching page... currently, for every word in a text string, i'm building into the sql query: "keywords LIKE '%" & keyword(0) & "%'"

is there a more efficient way of searching through this? is there some combination of doing this and using index's or something? i'm lost...

one last thing, stored procedures.... I've never worked with sql server before (never needed to), but now I would like to, and should really learn stored procedures....


REALLY appreciate the help and feedback...