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
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 shopping
cart?
TIA,
Victor
--
The Logos has come to bear
http://logos.13g
Ofer Inbar wrote:
I've been running this for a few hours and it consistently shows lots
of writes but no reads at all on sdb1, the partition where I have my
binary logs and tmpdir. Is MySQL writing lots of tmp files and not
reading them? Or, how else can I interpret this?
-- Cos
Perhaps t
Mathieu Bruneau <[EMAIL PROTECTED]> wrote:
> > BTW, here's another oddity I noticed - here's typical output from
> > "iostat 60":
> >
> > | avg-cpu: %user %nice%sys %iowait %idle
> > |7.350.003.590.94 88.12
> > |
> > | Device:tps Blk_read/s Blk_w
Ofer Inbar a écrit :
> mos <[EMAIL PROTECTED]> wrote:
>>> Why are so many small tmp tables being created on disk, not memory?
>>> How can I tell MySQL to use memory for these?
>
>>I'd guess these temporary files are the result of Select statements
mos <[EMAIL PROTECTED]> wrote:
> >Why are so many small tmp tables being created on disk, not memory?
> >How can I tell MySQL to use memory for these?
>I'd guess these temporary files are the result of Select statements
> with an Order By clause that requ
e | Value|
+---+--+
| max_tmp_tables| 32 |
| slave_load_tmpdir | /data/mysql/tmp/ |
| tmp_table_size| 67108864 |
| tmpdir| /data/mysql/tmp/ |
+---+--+
... and yet, I frequently see tmp tables on disk much smaller than 64M:
#ls -alF /data/mys
ables| 32 |
| slave_load_tmpdir | /data/mysql/tmp/ |
| tmp_table_size| 67108864 |
| tmpdir| /data/mysql/tmp/ |
+---+--+
... and yet, I frequently see tmp tables on disk much smaller than 64M:
#ls -alF /data/mysql/tmp/
total 1552
drwxr-xr-x 2 mysql
Hi Mark,
The system in question has 1GB of RAM in it. As far
as I can tell, the box does not get stuck swapping
when the system has a query (or several) in this
state. If I log in via the command line client and
kill the query, the system continues on it's way like
nothing was wrong in the first
thread_stack126976
> tx_isolationREPEATABLE-READ
> timezonePST
> tmp_table_size 209715200
> tmpdir /tmp/
> transaction_alloc_block_size8192
> transaction_prealloc_size 4096
> version 4.0.16-pro-log
> wait_timeout28800
>
> --- Mark Maunder
> I've been Googling unsuccessfully for specific
> issues
> > relating to queries run on MySQL version 4.0.16
> > against "tmp" tables. I have witnessed several
> > occurrences where queries running on various
> platforms
> > hang in a "Copyi
issues
> relating to queries run on MySQL version 4.0.16
> against "tmp" tables. I have witnessed several
> occurrences where queries running on various platforms
> hang in a "Copying to tmp table" state for hours or
> days at a time. When the same query is manu
Hi Everyone,
I've been Googling unsuccessfully for specific issues
relating to queries run on MySQL version 4.0.16
against "tmp" tables. I have witnessed several
occurrences where queries running on various platforms
hang in a "Copying to tmp table" state for hours or
Here are a number of queries that are run from time to time on the master. They are
always run together and in order that they appear.
Version of the server is 3.23.32 ( yes its old, but difficult to update at this time )
Version of the slave is 3.23.49a
Note: [param:] is handled by our own query
Hello,
I am continuing to have what seems to be intermittent problems with
replication. I have attempted to exclude temporary tables from replication
by using ignore wild specifications in my.cnf on both master and slave.
For some unknown reason there are times that MySQL still tries to repli
Hei
I think we have found a bug in mysql replication.
We have some programs that are working against a master DB and that use
temporary tables. The hole system works without problems until we run a
flush master/slave. Then the replication in the slave DB stops working
because of this.
How t
28 matches
Mail list logo
