On Fri, 2005-07-08 at 18:20, Chris W. Parker wrote:
> Hello,
>
> We have two websites. One website is already up and running, the other
> is not.
>
> The first website (I'll call it one.com) contains a large number of the
> products and is meant for a specific audience. The second website (I'll
> call it, yep you guessed it, two.com) will contain a small subset of the
> products that are currently available on one.com. It is meant for a
> different audience.
>
> Since two.com will have a subset of the products found on one.com I'm
> not sure which method of duplicating the data is the best.
>
> Here are some options I've come up with to handle this:
>
> 1. Create two completely different databases where a pricing update in
> one database will need to be made in the other database. This process
> would either be done manually or automatically through a cron job.
>
> PROS: Data integrity is almost nill since each records autonumber id
> will be based upon its own data and not old data from another db.
>
> CONS: A robust script will need to be created that can determine which
> db's data should be copied or not copied. e.g. Let's say I update the
> price for one of the products. That's an easy one because whichever
> record has the latest price_modified time wins. But then let's say I
> modify the description to include some promotional text for website
> two.com that I don't want to show up on website one.com? I either need
> to always ignore data like 'description', 'name', etc. or come up with
> some complicated way of telling the update script not to include certain
> changes. Complicated!
>
> 2. Create a new database with all the same structure as the original
> database except that it will not contain a products table. The product
> information will be retrieved from the original database.
>
> PROS: Data comes from only one place.
>
> CONS: Data integrity. What if a change happens in the original database
> that adversely affects the second? (I can't think of any examples at the
> moment.) Another con is that each product must have exactly the same
> data. I can't add promotional text to a product meant only for a
> specific website and leave it off the other website.
>
> 3. Add extra tables for the new website to the original database by
> prefixing a delimiter to each table.
>
> PROS: One database.
> CONS: This just seems more kludgy than the rest of them.
>
> e.g.
>
> Original db without modifications:
>
> products
> customers
> categories
> etc.
>
> Now with new website tables:
>
> products
> two_products
> customers
> two_customers
> categories
> two_categories
> etc.
>
> 4. Add a field to each table that will differentiate which website the
> record belongs to. e.g. 'SELECT * FROM orders WHERE website = 2'.
>
> Now that I'm thinking about it, this option seems to ultimately be the
> same as #1. I can't think of any inherent benefits to this option.
>
>
> Which option should I go for? Is there another option I'm not
> considering?
Use a bitvector field in the table and use a bitmask for filtering for
which sites can access what products. Then similarly for customizations
(presuming good database normalization) you can extend this to
customizations, specials, etc, etc. This is only one possible solution
of many, you could have the database list in another table, but I
thought I'd skip a join since you only mention two sites.
Pros:
- great data integrity
- single point of update
Cons:
- using bits (if that's really a con :)
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
