Scott0_: What are you.

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:

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_:

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?