Need for different store

Hi,
This might sound plain for experts, but certainly adds for me.
I was going thru Teamsite 6.5 windows admin pdf. It is mentioned that 6.5 supports 8 content store per installation. Also mentioned that we can have different web developments in diff branches.
For ex. project A and project B.
I can have two branches under main branch for these and go ahead.
my question is when to use the different content store?
Also when to decide to use a different branch?

I hope anybody in community will have some ideas on this.
appreciate your suggestions
thanks in advance
amit

Find more posts tagged with

Comments

iw_store

Hi,
This might sound plain for experts, but certainly adds for me.
I was going thru Teamsite 6.5 windows admin pdf. It is mentioned that 6.5 supports 8 content store per installation. Also mentioned that we can have different web developments in diff branches.
For ex. project A and project B.
I can have two branches under main branch for these and go ahead.
my question is when to use the different content store?
Also when to decide to use a different branch?

I hope anybody in community will have some ideas on this.
appreciate your suggestions
thanks in advance
amit

This purely depends upon your requirement and design..

Adam Stoller

Hi,
This might sound plain for experts, but certainly adds for me.
I was going thru Teamsite 6.5 windows admin pdf. It is mentioned that 6.5 supports 8 content store per installation. Also mentioned that we can have different web developments in diff branches.
For ex. project A and project B.
I can have two branches under main branch for these and go ahead.
my question is when to use the different content store?
Also when to decide to use a different branch?

I hope anybody in community will have some ideas on this.
appreciate your suggestions
thanks in advance
amit

What may not be clear is that each additional content store requires (legally) additional licensing (i.e. $'s).

In general, multiple content stores are used to either segment *large* backing stores (to improve management of disk space and backups and such) or for distinct projects -- though unfortunately, since there are still many centralized configuration files (e.g.: iw.cfg, templating.cfg, available_templates.cfg, etc.) the distinct-ness of the backing stores is primarly for content purposes and not (as much) for configuration purposes.

nipper

One other point fish does not mention is the political aspect of multiple projects. I have seen different divisions want to keep projects seperate and think that another store will provide some added benefit (maybe in time down for backup etc) so they purchase it. Not a true techical reason, but in corporate America, it also matters. And is cheaper than another server. Smiley Very Happy

Icebreaker

Hi Amit,

As Ghoti said, its mainly for content management we have different stores.

In my ealier project we had 3 stores with different Business Units as branches.
Here is the example...

AMERICAS - Store
Company
Employee
Products
Projects
Sales
Units

APAC - Store
Company
Employee
Products
Projects
Sales
Units

EMEA - Store
Company
Employee
Products
Projects
Sales
Units

Hope this gives some idea.

Regards,
Jay

RonaldV

Amit,

as for branches I think your are asking the 1M-dollar question of software developement. As in every CVS-like version control system the question is how to sub-divide your branches. It's all about editions, versions, privileges, deployments, releases, code/content merges, code/content-freezes, workflows, development process, release management, etc. Every situations requires a custom-tailored answer. 1-branch fits all vs. many layers deep.

The best answer is maybe to get advise from a Iwov-consultant or any other CVS-experienced consultant.

As for content-stores this is more a technical question. Maybe, content stores in TS can be compared to partitions on your harddisk.

But one remark, you can not copy content from 1 to store an other, without losing valuable info (extended attributes), though there are work arounds for this.

Cheers, Ronald