[Sigia-l] The Horror of Access Database

[Listera]

"karl fast" wrote:

> Web search engine queries have their roots in full-text information
> retreival systems. The query model in a relational database does not
> function the same way.

Not if you don't design it that way. I think it might be more useful to
break down the original problem into three parts:

     Interface
     Search
     Storage

Now, technically speaking, you *can* make a full-text system appear to be a
RDBMS type of search facility *and* vice versa, because essentially the
three components above can (and often should) act independently of each
other.

'Interface' is how you gather search criteria from the user. This could be a
single text field that could accept anything: words, phrases, Booleans,
natural language, etc. It could also be structured into distinct search
field criteria mapping to the DB columns. Obviously, it could be a
combination of the two as well.

Once you gather the search criteria from the Interface how you relate it to
the data is the Search mechanism. For example, you can parse the
single-field, natural-language criteria into components and try to map them
against DB columns. You can do the reverse: take distinct search fields,
concatenate them into Booleans under the rules meaningful to your data to
conduct full-text searches. This is more of a UI issue than an
insurmountable technical barrier.

Your Storage could be the actual documents as files on disk, converted to
XML or imported into an RDBMS, as well as some permutation of these. Again,
the important thing to remember here is that how you store the text/data
does *not* have to dictate what your Interface should look like, since
Search is the bridge/logic/abstraction layer between the two.

I've written at some length here fairly recently about using sets to index
full documents kept in a DB, to provide the advantages of both an RDBMS and
a full-text search type of interface, with the added benefit of returning to
the user an exact count of likely hits *without* a trip to the DB for a full
search.

Anyhow, my point is that any analysis of search/retrieval should really
consider the distinct nature of these three layers and how they can be wired
differently to achieve intended goals.

To that end, what DB one uses for storage is fairly inconsequential, for
general design purposes. Needless to say, DB2 or Oracle are far more capable
than, say, Access. But one can design a horrible system using any DB.
Frankly, I don't know why anybody who gets paid as a programmer would still
use Access today, but then again I don't understand why anybody uses the
only OS Access runs on either :-) I'm fairly certain of this: if a
programming group is firmly wedded to Access, take it as a sign that
interesting solutions are often beyond their interest or reach.

Best,

Ziya