Browse Prior Art Database

Internet Access to Databases with User-Defined Fields

IP.com Disclosure Number: IPCOM000119010D
Original Publication Date: 1997-Oct-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 2 page(s) / 109K

Publishing Venue

IBM

Related People

Mulder, SJ: AUTHOR [+2]

Abstract

Software solutions can often have improved customer value when they are closely integrated with specific customer data. However, making a solution generic enough to encompass the wide variation in customer data is often very difficult.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 47% of the total text.

Internet Access to Databases with User-Defined Fields

      Software solutions can often have improved customer value when
they are closely integrated with specific customer data.  However,
making a solution generic enough to encompass the wide variation in
customer data is often very difficult.

      Such was the case in the design and implementation of the
"catalog services" component of the VideoCharger product.  This
software solution needed to provide easy internet access to a
customer's database  of video files.  The design goal was to allow an
end user to query the  video database from a Web browser and select a
video for playback. The  major problem of this goal was the need to
address a wide variation in  the contents of the customer databases.
Since customers ranged from universities to insurance companies to
movie studios and beyond, there  was no ability to dictate the
contents (or fields) of the customer databases.  While a movie studio
might be interested in the title, producer, director, and year of a
video, an insurance company would be  interested in the claim number,
policy number, and Underwriter Identification (ID) associated with a
particular video file; and videos  stored in a university database
might be referenced by course number, section number, instructor, or
assignment number.  Clearly, the "least  common denominator" of
database fields was unlikely to be found that would satisfy all our
customers.

      A traditional, and somewhat obvious solution, would be to
categorize customers and provide a range of database support that
would work with various industries.  This solution would have
mandated the fields in the customer database and provided queries
that used those fields.  While this would have worked, it would have
been overly restrictive for customers, and it would have required
development of multiple database query routines.

      Another solution would have been to adopt a more generic query
interface, one more along the lines of a general purpose DB/2
Structured Query Language (SQL) query utility.  This would have
allowed customers  full flexibility in defining their databases.
But, it would have sacrificed a significant amount in terms of "easy
internet access." End  users would have to understand more about
database tables than we would  have liked.  Also, it would have made
for a more cumbersome integration  of the customer data with the
VideoCharger solution.

      Our solution was to provide customers with a tool for creating
their databases which would allow them to specify whatever fields
they wanted.  The tool added some special values in the database
which made it  "self-defining" to a query facility which we also
provided.  The database  could still be used by traditional database
utilities; the special values  were, for the most part, hidden from
normal database queries or operations.

      The provided query facility was invoked from the W...