Oracle7 & Printing/Publishing (Re-Post)

Is Oracle7 Server viable in the scenario that follows?

In the printing and publishing industry there is a large requirement for tracking textual based information. Not all such companies produce high quality commercial 4-colour, glossy work. Many produce, relatively speaking, low grade, black on white, perfect bound text book work. Oracle themselves is a large consumer of such printing and publishing services. Consider the number and volume of books that accompany their product sets. Their books generally contain few graphics, are printed exclusively using black ink and generally have a fixed size dimension. The market for this kind of printing is very large.

I have a customer who prepares this kind of material in a big way for many customers. They need to automate the fashion in which they track their customer's textual based information that goes into the preparation of a book. They have explored proprietary pre-press systems from firms within the industry. These systems are not a good fit. They are geared toward commercial 4 colour producers, not text based producers. This firm is contemplating building their own front-end, pre-press system potentially using Oracle7 as the database manager, back-end of this textual based information. They see Oracle and Oracle7 as viable options because of the product's portability and scalability.

They have some questions though, that I will try and articulate. Perhaps some of the big guns at Oracle would like to engage this article or others who feel versed. Please feel free. (Thank you for you patience.) Here we go:

• This company requires a system that will accommodate PageMaker and Quark Express front-ends running in both the "PC/DOS" and Mac environments with multiple connects: Oracle fits the bill here. However, what kind of difficulties might we anticipate in linking text based information from Oracle databases with these said GUI based front-ends?
• The basic unit of information is a text page. Oracle's RDBMS is good at handling traditional transactional based information but how well could it handle textual based information in this context or regard? If I am a pre-press technician at a workstation and I need to change a "typo" on page 112, paragraph 3, of a specific title, I will need to be able to do this quickly with a minimum amount of "fuss". This is required in a busy, real-time production environment. I also need to be able to index a specific customer title among ten or fifteen titles that might apply to that customer at any given time.
• What would be the basic "transaction" unit? A "long" datatype? I don't believe you can search on these datatypes. This firm needs to be able to access the information on the following levels: on a customer title by title basis; at the character, page and chapter levels. What kind of relational table or structure would accommodate such a beast? I have a good idea about the indexes mentioned, but what about the text itself?

In essence what they need to be able to do is accommodate the "book paradigm" within the confines of the Oracle7 RDBMS while utilizing it's strengths as a database manager. Perhaps a later version of Oracle7.X is what they'll require. The solution must be reasonable with an emphasis on simplicity. Oracle has such products as Oracle Book and SQL*Textretrieval which suggests that they are actively doing work in this area. Would these products and other OEM products be viable in this company's production, dead-line oriented environment?

All comments are welcome.

Thank you

PB
Berger Software Received on Thu Feb 24 1994 - 15:49:15 CET