On Thu, Jan 14, 2010 at 1:35 AM, Chris W <4rfv...@cox.net> wrote:
> I think the reason the other poster was so harsh is because others have
> suggested the right way to do it, if not in a lot of detail, and you have
> just argued with them.
>
I don't recall anyone doing that. I don't recall argui
Victor Subervi wrote:
You're so complimentary! Wouldn't it have been better to simply suggest FKs?
I think the reason the other poster was so harsh is because others have
suggested the right way to do it, if not in a lot of detail, and you
have just argued with them.
Since I'm not in
On Wed, Jan 13, 2010 at 2:33 PM, Johnny Withers wrote:
> No one designs a shopping cart system this way.
>
> http://www.google.com/search?q=shopping+cart+database+table+design
>
> If you are dead set on this crazy design it doesn't matter if you put the
> temp tables in the main database or anothe
No one designs a shopping cart system this way.
http://www.google.com/search?q=shopping+cart+database+table+design
If you are dead set on this crazy design it doesn't matter if you put the
temp tables in the main database or another database. It'll be just as silly
either way.
JW
On Wed, Jan
On Mon, Jan 11, 2010 at 3:21 PM, mos wrote:
> At 09:56 AM 1/11/2010, Johnny Withers wrote:
>
>> Victor,
>>
>> The temporary table solution is not a good one. Use a single table and
>> store
>> each item put into a cart identified by the session ID of the user. A
>> process should clean out this t
At 09:56 AM 1/11/2010, Johnny Withers wrote:
Victor,
The temporary table solution is not a good one. Use a single table and store
each item put into a cart identified by the session ID of the user. A
process should clean out this table periodically since there are "shoppers"
that abandon carts f
Victor,
The temporary table solution is not a good one. Use a single table and store
each item put into a cart identified by the session ID of the user. A
process should clean out this table periodically since there are "shoppers"
that abandon carts from time to time.
The design of this table cou
On Mon, Jan 11, 2010 at 11:38 AM, Keith Murphy wrote:
> Victor,
>
> Don't want to butt in, and not trying to be rude, but he gave you advice.
> You don't seem inclined to take it. How else can he, or anyone else, help
> you? Clearly you don't understand some fundamental issue about relational
> da
Victor,
Don't want to butt in, and not trying to be rude, but he gave you advice.
You don't seem inclined to take it. How else can he, or anyone else, help
you? Clearly you don't understand some fundamental issue about relational
databases. If you can't just accept his suggestion to put all carts
On Mon, Jan 11, 2010 at 10:49 AM, Baron Schwartz wrote:
> Victor,
>
> > That strikes me as messy. Each tmp table has as many rows as necessary
> for
> > the products that are to be bough. To do as you say I would have to
> create a
> > table with a zillion rows to accommodate however many product
Victor,
> That strikes me as messy. Each tmp table has as many rows as necessary for
> the products that are to be bough. To do as you say I would have to create a
> table with a zillion rows to accommodate however many products I *predict*
> buyers would buy. Therefore, I guess I should probably
On Mon, Jan 11, 2010 at 10:35 AM, Baron Schwartz wrote:
> Victor,
>
> On Sun, Jan 10, 2010 at 1:20 PM, Victor Subervi
> wrote:
> > Hi;
> > I have a shopping cart that will spawn a tmp table for every shopping
> cart
> > instance. Would it be better to create a separate database for these
> inste
Victor,
On Sun, Jan 10, 2010 at 1:20 PM, Victor Subervi wrote:
> Hi;
> I have a shopping cart that will spawn a tmp table for every shopping cart
> instance. Would it be better to create a separate database for these instead
> of having them in the same database as all the other tables for the sh
13 matches
Mail list logo
