Re: Design decision

2007-10-03 Thread Brent Baisley
I'm not sure why you say 30 or more inserts will take too long. As long as you do a bulk insert, it's just a single command. 30 individual insert will take it's toll. You are really looking for a logging system. Your not going to be querying the table all that much, just a lot of inserts. S

Re: Design decision

2007-10-03 Thread Chris
Scott Haneda wrote: Scott Haneda wrote: I have an a table of objects, attached to those objects are keywords. Users submit the keywords to the objects. Currently, I chose to keep a hit count on the keywords, so if a duplicate keyword is supplied, a counter is incremented. I thought this was a

Re: Design decision

2007-10-03 Thread Scott Haneda
> Scott Haneda wrote: >> I have an a table of objects, attached to those objects are keywords. >> Users submit the keywords to the objects. >> >> Currently, I chose to keep a hit count on the keywords, so if a duplicate >> keyword is supplied, a counter is incremented. >> >> I thought this was a

Re: Design decision

2007-10-03 Thread Chris
Scott Haneda wrote: I have an a table of objects, attached to those objects are keywords. Users submit the keywords to the objects. Currently, I chose to keep a hit count on the keywords, so if a duplicate keyword is supplied, a counter is incremented. I thought this was a good idea, as it keep

Design decision

2007-10-03 Thread Scott Haneda
I have an a table of objects, attached to those objects are keywords. Users submit the keywords to the objects. Currently, I chose to keep a hit count on the keywords, so if a duplicate keyword is supplied, a counter is incremented. I thought this was a good idea, as it keeps the number of rows i

RE: Design decision

2003-07-28 Thread csebe
> From: Lin Yu [mailto:[EMAIL PROTECTED] > Sent: Monday, July 28, 2003 9:33 PM > To: [EMAIL PROTECTED]; 'mysqllist' > Subject: RE: Design decision > > > Lian, > > Between your design solutions (1) and (3), you need to decide, > from the logical > business

RE: Design decision

2003-07-28 Thread Lin Yu
: Design decision Hi everyone, Just wanted your expert opinion on the following: I'm implementing an authorization system with user/group permissions stored in a database. I have a Users table and a Group table, identical in structure: mysql> desc users; mysql>

Design decision

2003-07-28 Thread csebe
Hi everyone, Just wanted your expert opinion on the following: I'm implementing an authorization system with user/group permissions stored in a database. I have a Users table and a Group table, identical in structure: mysql> desc users; mysql> desc groups; +---+-+ | Field | Type

Re: Design decision on generating data

2002-04-12 Thread Steven Hajducko
Usually I build my queries dynamically. I store all the values into a hash ( this is in perl mind you.. ) Then do something like this.. my (@fields, @vals); my ($field_str, $val_str); foreach $field_name (keys %hash) { if ($hash{$field_name}) { push @fields, $fie

Re: Design decision on generating data

2002-04-12 Thread Carl Schmidt
Thank you for the information. Let me please clarify that i am using a web form. I tried the one solution of converting those values that are not set to null, but mysql complained: SQL: INSERT INTO Development_Event_Show(showID,venueID,description,ageCutoff,ageDelimiter,price1,price2) VALU

Re: Design decision on generating data

2002-04-12 Thread Christopher Thompson
On Friday 12 April 2002 8:10 pm, Carl Schmidt wrote: > I have a form where a user enters some numbers into text boxes. Some of > the text boxes can be left blank. The business logic receives all > variables to all text boxes. Should I : I'm assuming that you are using an executable file and NO

Design decision on generating data

2002-04-12 Thread Carl Schmidt
I have a form where a user enters some numbers into text boxes. Some of the text boxes can be left blank. The business logic receives all variables to all text boxes. Should I : 1.) Validate on the page for the presence of a value, and if not, set the corresponding value to -1 (it will never b

Re: Bug in 3.23.33? Or design decision?

2001-03-07 Thread Steve Ruby
[EMAIL PROTECTED] wrote: > > Hi! I just upgraded from 3.22.26a to 3.23.33. We've got a database > that has a table that has a column with the name: FullText. Unfortunately, > now with 3.23.33, any queries that explicitly refer to this column/field > return an SQL error. So far this ha

Re: Bug in 3.23.33? Or design decision?

2001-03-07 Thread alex
Mensaje citado por: Peter Skipworth <[EMAIL PROTECTED]>: > fulltext is now a reserved word - either change the name of the field, > or use quotes when refering to it. > > [EMAIL PROTECTED] wrote: > > > Hi! I just upgraded from 3.22.26a to 3.23.33. We've got a > database > > that has a tabl

Antwort: Bug in 3.23.33? Or design decision?

2001-03-07 Thread alexander . skwar
On 06.03.2001 19:05:34 iso-8859-1 wrote: >Is this expected behavior? Or is this an actual bug? I suppose this may be expected behavior, as FullText now is a reserved word in MySQL - Before posting, please check: http

Re: Bug in 3.23.33? Or design decision?

2001-03-07 Thread Peter Skipworth
fulltext is now a reserved word - either change the name of the field, or use quotes when refering to it. regards, P On Tue, 6 Mar 2001 [EMAIL PROTECTED] wrote: > Hi! I just upgraded from 3.22.26a to 3.23.33. We've got a database > that has a table that has a column with the name: Full

Bug in 3.23.33? Or design decision?

2001-03-07 Thread eric
Hi! I just upgraded from 3.22.26a to 3.23.33. We've got a database that has a table that has a column with the name: FullText. Unfortunately, now with 3.23.33, any queries that explicitly refer to this column/field return an SQL error. So far this has been tested with SELECT and UPDATE