| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Comments:
<0> sometimes use datetime even if you want timestamp
<0> depending on version
<1> Errm...
<1> Well aht difference does it make?
<0> what kind of date/time information are you talking about?
<2> i just use int for a timestamp :S
<1> At the end of the day I don't know what the difference is so long as I can store the date/time
<0> then you probably want datetime.
<0> timestamp is for storing when a record was inserted or updated automatically
<3> well a timestamp updates whenever you change the data in a row, a datetime does not
<1> Yes I want to be able to do that
<3> sort of :P
<0> you want to be able to do what?
<3> if you want the timestamp to update every single time you change any data then you should use a timestamp
<1> Store when a record was inserted and when it was updated
<0> then yes, use timestamp
<3> if you don't want it to then you should use a datetime and manually set it to now() in each update or insert where you want it to change
<0> in 4.1+ define it as "timestamp default current_timestamp on update current_timestamp"
<1> Ah so it will update it EVERY time, I can't tell it not to?
<0> in 4.0 just define it as timestamp
<1> That pretty much answers my question, thanks :D
<0> if you only want it to log insert and you're using 4.1+ do "default current_timestamp"
<0> and lose the "on update" bit
<3> oh nice :P
<0> if you want it to change on update in general, but want to override it, just specify "tscol=tscol" in your update
<0> update mytable set mycol=1,tscol=tscol where ...
<0> and it won't change
<3> i have found that that approach causes problems sometimes
<0> you have to remember to do it
<3> yup
<0> in 4.0 if you only want it to be set on insert, i'd honestly just use NOW() when i insert
<3> i would do that on any version
<1> so does now() do timestamp or datetime?
<0> either
<1> i c
<0> it can be inserted into either
<3> they are both the same mt3
<1> I think I'll just use datetime
<3> they just behave differently when you insert data into a row and do not specify them explicitly
<1> Seems to be more reliable if I don' knwo the specific version etc. the user will be running?
<3> there are probably some other differences too :P
<0> yeah, it is mt
<0> 3
<1> Ok I'll do that
<1> Thanks guys
<3> now the really tough question is "for dinner should i make macaroni cheese or should i make lasagne?"
<4> mac n cheese
<5> what's the difference between a primary key and an index?
<3> well a primary key uniquely identifies each row
<3> an index is like an index in a book
<5> okay
<5> so a primary key should usually be the "id" tabe for a record?
<3> i like it to be
<3> but there is no general requirement that that is the case
<5> but say you do a lot of WHERE blah = 'this'
<5> and INDEX would be beneficial on blah ?
<0> yes
<0> in general.
<6> tek: It can depend on the data as well.
<5> say you do conditionals on primary keys, should you have primary AND an index?
<3> can ?
<3> i would say it *does* depend on the data :P
<0> a primary key is a type of index
<5> or an index on a primary key, iguess?
<5> which offers more performance?
<3> an index on a primary key would probably degrade performance
<5> because it's twice as much to do?
<5> or not necessarily twice
<3> because the primary key is already implicitly an index
<6> tek: It's not always a given that an index will help.
<5> when does it help?
<5> (i've been reading about optimizing a lot)
<3> it is a non-trivial problem
<3> the best way to find out is to experiment a lot
<3> and use common sense
<5> yeah
<6> tek: In some cases an index can hurt performance rather significantly.
<3> yup
<5> in which case would that be? a table with < 100 rows?
<3> not necessarily
<3> although it is unlikely that you would see any performance gain from an index on a table with 100 rows :P
<5> but an index on a table that simply returns data is useless because an index is primarily for making FINDING the row easier with integrity, or strong references?
<0> an index on a boolean column is useless, as well
<5> right
<5> because an INDEX helps FINDING the row easier, it doesn't return the actual data you're requesting any faster, right?
<5> like SELECT u.name FROM users u WHERE u.id = 1
<0> sometimes you can use an index for the entire query
<5> u.name doesn't need an index, because it's just data
<5> what do you mean by that?
<0> say you did: select name,address from users where name='bob'
<0> and you have an index on name,address
<5> ah, right
<5> that would benefit?
<3> well it would probably be quicker to have the index on name in most cases rather than name,address for that particular query
<0> well yes, probably
<5> but what you have a condition where you need WHERE address=''
<0> then that index won't help
<3> but his point was i think that if all the data can come from the index mysql will not even query the table itself directly
<0> yes, correct
<5> ah
<5> makes sense
<3> which is how you would hope it would behave :P
<5> lol
<5> also, I have a table called "friends" That is symmetric
<5> I just didn't know that until someone told me, can you explain symmetric tables to me? or give me a link to an article ?
<7> I kinda feel silly asking this .. I must be misreading this LOCK TABLES section. Is there a way to do a SELECT .. then an UPDATE and ensure that no other process can do a SELECT 'between' the 2? using MyISAM tables
<8> in freebsd, there are mysql 5.1 and 4.1 versions available.. which one would you recommend?
<0> of those two, 4.1
<0> and smack whoever maintains the mysql ports and make them add one for 5.0
<0> 5.1 is still beta
<0> and 4.1 is out of date
<8> 5.0 is there already
<0> so what's wrong with 5.0?
<8> but i thought, 5.0 is no productive version?
<0> 5.0 is GA
<4> 5.0.x
<0> 5.1 isn't.
<8> "GA"?
<4> generally available
<0> generally available
<8> GA ~ "rocksolid"?
<8> ah
<4> ^5
<8> ok
<9> Hey guys. Can anyone help me with a mysql cluster?
<0> yes: don't use it. you don't want it, you just think you do
<5> I also recently switch my table from MyISAM to InnoDB
<5> because I read that it is "better"
<9> lol
<0> it's better in many cases, yes
<0> not in all
<5> why though?
<5> no one ever really gave me a straight answer just "it's better"
<0> row level locking, transactions, foreign keys, fully acid
<7> isn't it higher overhead, though?
<9> its to so hard up a cluster. :(
<9> :~
<0> you don't want cluster bico
<0> i wasn't kidding
<9> sure?
<9> i dont want of course.
<0> why do you think you need cluster?
<9> my boss want make some tests.
<9> :(
<0> how big are your databases?
<9> a little.
<0> how many servers do you have dedicated to mysql?
<5> a little big?
Return to
#mysql
or
Go to some related
logs:
#lisp
can't use string as a hash ref irssi
#ubuntu
#gimp
illegalc0de
home/.dmrc file is being ignored gentoo
gentoo gccmakedep not found
gentoo hda: dma_timer_expiry: dma status == 0xff
#linux
at
|
|