Designing the Catalog Repository : A Simple Overview

If you are designing a multi-locale site with catalog repository content, you can set up your catalog repository in one of two ways. You can create a separate repository for each language or with a single repository for all languages.

A catalog repository is similar to other SQL repositories. There are three main parts:

The database schema on your SQL database server.

The repository component, which is of class atg.adapter.gsa.GSARepository.

The repository definition file, which is an XML file that defines the relationship between the SQL database and the Dynamo repository component.

This section discusses the pros and cons of single and multiple repository configurations. The option you choose dictates how you must set up your database tables. If you have a repository for each locale, you should also have database tables that contain different product information for each locale. If you have a single repository, you can separate your database tables so that the locale-specific properties of each product are stored in multi-valued tables that hold many different language versions of the same information. When you are designing your catalog repository, consider the following pros and cons of each design:

Multiple Repositories

Create a separate content repository for each language. This requires separate targeting rules for each locale, in which each rule references the appropriate language repository. This is the simpler of the two methods.

Pros: Separate targeting rules let you target different pieces of content to different locales. For example, site visitors from Japan may not be interested in the same style of jeans as site visitors from the US.

Also, administration of multiple repositories is easier than a single repository, because you can have a catalog administrator for each language who has access only to the appropriate repository.

Cons: You must maintain multiple copies of each item in the repository, since each item is duplicated in each locale-specific repository. In addition, storing separate values for each locale-sensitive takes up a lot of space in the database.

One Repository

Configure a single repository for all languages and include a language attribute in each repository item. This method requires you to develop logic that uses the RequestLocale’s localeString property to get the property values corresponding to the proper locale.

Pros: You can maintain only one copy of each repository item. These items draw their locale-specific attributes from a multi-valued table in the database.

Cons: This configuration is more difficult to administer because data for every language is in one repository. You cannot separate products that are Japanese-specific, for example.

You have to store most languages other than English in UNICODE format, which takes up 2 bytes per character, instead of ASCII, which only requires one byte per character. If you are using separate repositories, you can use ASCII and UNICODE where appropriate, but if you have a single repository you must store all data in UNICODE. This takes up more space in the database.

There are more database joins in a single repository because of the large number of multi-value tables. This slows Dynamo operation. The reduced performance may be imperceptible, but using multi-value tables does increase the load on the database.