Cross platform search database

[Frank D. Engel, Jr.]

The easiest way to set up all of the searching, etc. for a large 
database would be to store all of the data in an SQL database and let 
the database server worry about indexing, searching, and sorting 
results; however, this would require there to be an SQL database server 
running on the machine in order to query the results.  Not a 
particularly nice thing for running such a program from a CD.

However, there is also the possibility of an *embedded* database 
server, which would place a miniature database server into your 
application.  I have personally not tried using one of these, but it 
may be worthwhile for you to research one.  Rev supports one called 
"Valentina" (spl?), the advantage of this approach is that you get the 
search and sort capabilities of a database server, the database engine 
handles the disk-to-RAM issues for you, and there is still nothing for 
the end-users to install: the database server would run inside your 
created standalone application with no network access or anything to 
worry about, and all of the data gets stored in a file on your CD.  It 
would be completely transparent for your end users, and simplify your 
life considerably.

On Dec 4, 2004, at 9:59 AM, MisterX wrote:

>
> Hi Jesse!
>
>> I would like to build a cross platform app that would be
>> shipped on a CD-ROM that contains a whole collection of html files.
>
> We'll see about that! I'll give you another approach list that could
> maybe fit...
>
>> Previously, we had to depend on a Java applet, but that had
>> all sorts of problems with XP and also OS X and works on
>> certain browsers only.
>> I would like to abandon that and use Revolution as the engine
>> if possible.
>
> Very good choice! You'll see that you can go beyond HTML in no time
> without much trouble and better results just like in the old days!
>
>> My question is this: What would be the best approach to building this?
>
> Since HyperCard, the stack is the dataholder and the application.
> This is one approach. The other which is the application accessing
> the data stored externally is the lighter approach. Memory isn't
> usually a problem but oversized stacks can be.
>
> So you can easily create a GUI to browse through the folders and
> load the data from text files. I find it easier to grab data off
> stack files (which can be encrypted and loaded hidden!) It all
> depends on the data...
>
>> I did have some preliminary code to recursively decend down a
>> series of folders and then the general idea would be to load
>> up the text into cards and allow text searching on those cards?
>
> Well, if the stack has the text files imported, you wont need to
> reload them after. A stack is also very easy to search...
>
>> My understanding from some of the previous discussions is
>> that the entire stack is loaded into memory and that would
>> mean that the more content there is, the more memory would be
>> required for that.
>
> The optimal size depends on the granularity of your data.
>
> Lots of records or huge records or both?
> Lots of searching "what?"
>
> You can always index stack content and distribute it like a linked
> list or double linked list record database (you keep a link to a
> card in a stack and that's a link! This is really fast for multi
> leveled records or hierarchical databases.
>
> Imagine you have a dictionary or encyclopedia.
> You can't put it all in one stack!
>
> So you can break it down into subjects or alphabetical groupings
> or usage frequency or by geographical / ethimological source!
>
>> Are there any other approaches to this? Can a stack keep most
>> of its data on the hard disk and still be searchable for its text?
>
> Yes. Yes! But I would keep images separated... If there's over a
> hundred images, keep them off-stack with the relative path to the
> image. You can ammend the real path at runtime or preload the images
> into the stack you display - choices are infinite...
>
>> I don't have a problem with keeping the redundant text inside
>> Revolution stacks. My goal in the long term is to do away
>> with the html files totally (lots of legacy files) and to
>> have everything presented from within Revolution itself.
>
> no prob. RunRev apps run locally or off the pc without installers.
> I would assume the same from Macs or Linux but not sure as I've
> not tried them yet.
>
>> The goal is to allow text searching, which will show up a
>> bunch of hits in a window and a scrolling list and then allow
>> the user to click on one of those choices and then launch
>> back into the browser window to see the actual file.
>
>> I would appreciate it if there are any pointers or
>> suggestions as to how to best go about doing this.
>
> There's at least a million stacks out there with examples of
> databases. Lots of links to show... But I can proudly say you
> can find examples for all you want in monsieurx.com.
>
> You have HTML parsers - the DiscreteBrowser stack
> You have databases - Search for csv (a simple csv file importer
> with field parser to create a stack database.
>
> Or search for xos an advanced virtual database meta-format OS.
> There's an example self documenting of sorts stack too...
>
>> In the old days of Hypercard and Supercard, it would have
>> been a matter of just throwing everything into individual
>> cards on a stack and the stack contents are paged from the
>> hard drive. If everything is preloaded into memory in
>> Revolution, then I might have a problem ultimately as the
>> contents grow before I am able to make a full transition a
>> cd-rom that's entirely done using Revolution.
>
> Still is actually! Just with mo features to throw at the client!
>
> Cheers
> Xavier
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
-----------------------------------------------------------
Frank D. Engel, Jr.  <fde101 at fjrhome.net>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten 
Son, that whosoever believeth in him should not perish, but have 
everlasting life.
$



___________________________________________________________
$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com