Wittmann: Such that cascading to them might change something
Castilla: Ahhhhh i hadn’t considered that.
Correl: Aeiou: You said you get FK error, but your table does not have FK constraint.
Correl: Aeiou: Whenever you get FK error you check the other table too
Correl: Aeiou: Simplest example is fine. Wrong example does not help :
Duskey: Ok querying information_schema shows 37 tables linked to this table with FK. I will have a quick check of each of them. Still a little confused if they have a FK constraint how updating the table they are refrencing can cause a duplicate number because they would already have to reference the number right? and there is no eav_attribute with id 51?
Correl: Aeiou: ON UPDATE CASCADE .
Fenney: Riight getting there, let me just post an update
Fegaro: This explains the error: http://pastebin.com/raw.php?i=53ZadCHz
Cherny: However. how can this tables “attribute_id” be 51, since it has an ‘on update cascade’ and the table it references does not have a value of 51?
Butrick: Is the only answer that it was inserted when FK constraints were disabled?
Ambers: Its been a while since I’ve created indexes. when creating a multi column index, is it better to order them by the smallest subset?
Rainone: Not sure if im making sense there
Correl: Scott0_: If you mean the order of columns in the index definition it affects the queries
Ackermann: For instance if there are 3 possible values for column a and 10 possible values for column b. should I be setting the index as a,b?
Izsak: Pedward: it can be on some inlined spinlock there or something
Kemper: Scott0_: http://www.percona.com/files/presentations/percona-live/london-2011/PLUK2011-practical-mysql-indexing-guidelines.pdf
Syal: I know the order is affected
Tauares: Scott0_: doesn’ particulately matter to my understanding but feel free to test.
Hodgson: I guess ther term I was lokoing for is cardinality
Correl: Scott0_: Depens on queries. If you always do WHERE a=1 AND b=2; order doesn;t matter much. If you have WHERE clauses like: WHERE a = 1 AND b 2; then it should be a,b
Virgel: Is it low to high or high to low order?
Scowden: My query will be built to the best index
Correl: Scott0_: Nope. It is dictated by the queries :
Stalma: My query isn’t built yet and I can approach from a few angles due to the relationships
Correl: Scott0_: If your index is b,a WHERE a = 1 AND b 2; will not use it efficiently
Donado: Read above. will answer most questions. come back if it down’t
Wold: So im looking to get the most out of it and then tailor the query to the fastest index
Correl: Scott0_: Indexes exist to help certain queries perform better.
Rekemeyer: Tailor indexes to queries.
Christoforou: You’ll end up with a mess otherwise.
Kleifgen: There isn’t a single way to write the query
Correl: Scott0_: Do the opposite. Write your queries first and then find out what indexes help them best
Yanos: I could do any variation on order with the query, only one will be better than the rest
Kopis: Any variation in the WHERE would give the same result
Bichsel: Thanks for help all. Going to remove the floating rows = clearly shouldnt be there.
Auguste: Therefore I should be able to tailor the order of the items in the queries WHERE section by the best order for the index
Swancutt: Scott0_: leftmost prefix of columns with an EQUALITY match
Monterrosa: Then indexes aside, maybe im just asking about which order is best for the query itself
Mcneer: Scott0_: According to our chadmaynard don’t say his name, indexing order is: join, where, sorts, group by
Correl: Scott0_: What are you talking about?