Home Page   #c  #ruby-lang  #cisco  #mysql  #apache  #javascript  #java  #perl  #php  #openmoko   Wallpapers Girl
Reliable $1 Web Hosting by 3iX

Channels


#mysql

05 October 2007


Total 19 pages. You are browsing page 19/19.

First :: Prev :: [...] [15] [16] [17] [18] [19] :: Next :: Last

22:55 <****> "HoTMaiL"?
23:02 <****> Seekwill : are you trying to cheat at hangman? =P
23:03 <****> :)
23:03 <****> no, he is trying to make an unbeatable hangman bot
23:03 <****> I may be wrong, but I think I saw something like that once... I think it's called a dic-tio-na-ry
23:04 <****> But it needs to be able to use multiple words
23:04 <****> why wut thad be yousful?
23:04 <****> o.O
23:08 <****> aren't COUNTs "free"?
23:08 <****> (they're cached)?
23:08 <****> depends
23:08 <****> using MyISAM
23:08 <****> COUNT(*) is stored as table metadata
23:08 <****> with MyISAM
23:08 <****> as long as you don't have a where clause
23:09 <****> ah, so WHERE causes it not to be free?
23:09 <****> noi
23:09 <****> or does it cache it after called once?
23:10 <****> if you use the mysql query cache, yes
23:16 <****> hi guys.. i have a sproc heavy c# application that is experiencing performance problem with sproc execution. It seems that it's doing a full table scan on INFORMATION_SCHEMA.ROUTINES for every sproc hit
23:16 <****> in our case we have hundreds of catalogs with ~10000 sprocs
23:16 <****> hmm well information_schema is not really prominent for it's high speed
23:17 <****> nils_, yea i can understand that. but MySql.Data.dll seems to rely on it heavily for looking up the procedure body
23:17 <****> this lookup is very slow
23:17 <****> yeah
23:17 <****> it shouldn't do that
23:17 <****> is there any way i can put an index on INFORMATION_SCHEMA.ROUTINES
23:17 <****> hmm these aren't even actual tables.
23:18 <****> i tried as root but it told me access denied
23:19 <****> yea this is a pretty major roadblock for us (we're an open source wiki company: www.mindtouch.com)
23:19 <****> does reggie b ever stop by here?
23:20 <****> hi people.
23:20 <****> i have a question...
23:20 <****> how i disable the auto_increment in a table?
23:21 <****> max_m: don't know him.
23:21 <****> nils_: i think he's the maintainer of the .net connector
23:21 <****> DanyWalker_busy: with alter table, just modify the column to a column def that doesn't include auto_increment
23:21 <****> max_m: That might very well be true
23:22 <****> mmm
23:24 <****> im trying to figure out the proper syntax for a JOIN query: i need track.id, track.name, and artist.name on the condition of track.title_id = title.title_id AND title.artist_id = artist.artist_id can anyone help?
23:27 <****> what is your error message?
23:28 <****> dkr: you talking to me?
23:28 <****> yes
23:28 <****> mysql is usually pretty good about telling what part of the query has erroneous syntax
23:30 <****> dkr: ah you know, i just figured it out :)
23:30 <****> thanks :)
23:33 <****> ascendvisual SELECT track.id, track.name, artist.name FROM track JOIN title ON track.title_id = title.title_id JOIN artist ON title.artist_id = artist.artist_id
23:33 <****> nothing hard aboo tit
23:33 <****> *aboot it
23:33 <****> adaptr: yea, it one of my conditions was failing because i overlooked my data values :\
23:34 <****> thanks though
23:34 <****> conditions ? what conditions ?
23:34 <****> you never mentioned any "conditions" :)
23:41 <****> hi. when people post articles in my applicatoin, they can choose between a list of categories by their IDs. what's the best way to check, when receiving a subset of these, that they're in fact valid?
23:42 <****> would I construct a database request that checks where id = A or id = B or id = C, and so on, hoping the number of IDs for the posted article doesn't exceed the maximum length of a SQL request?
23:43 <****> or would I download the list of valid IDs and do a comparison in my programming to see if there were any invalid IDs fed back?
23:51 <****> simon you either use IN, or let users actually *select* categories, in which case they are guaranteed to exist
23:51 <****> IN is fairly fast, but still not recommended for arbitrarily large sets
23:52 <****> adaptr, they do actually select them in the application, but they can fake HTTP requests.
23:53 <****> if you're worried about that, then you should re-design your application to withstand abuse...
23:53 <****> I wouldn't worry about it until it has been shown to present an actual problem
23:53 <****> adaptr, I'm currently designing it, so I'm not far off your suggestion. :)
23:53 <****> make it work first, optimize later
23:53 <****> good point.
23:54 * simon jots down to fix it later
23:54 <****> that's the way to do it!
23:54 <****> yeah. especially when I'm on a timeframe.
23:54 <****> for now, use IN so you can get on with what you've got, if you feel th eneed to check
23:55 <****> but I wouldn't check - you could insert a dummy procedure that returns and fill it in later, as per the extreme programming credo
23:55 <****> nah, I'll just let people fuck around with it.. it won't actually hurt if the database has a few bogus IDs.
--- Log closed Sat Oct 06 00:00:54 2007


Total 19 pages. You are browsing page 19/19.

First :: Prev :: [...] [15] [16] [17] [18] [19] :: Next :: Last


Tutti i nuovi CAP Italiani. Come ottenere il database completo