Обновлление таблицы суммой значений из другой

[Василий М.]

На этапе проектирования лоханулся.
Есть таблица объявления, есть таблица изображения, содержащие ID объявлений.
Нужно в таблице объявлений сделать поле кол-во_изображений.
Как проапдейтить таблицу без PHP? Чисто средствами SQL?

 

[Gas]

совсем разленился

UPDATE `объявы` AS p
  JOIN (SELECT объява_id, COUNT(*) AS cnt FROM `картинки` GROUP BY объява_id) AS t ON t.объява_id=p.id
  SET p.images_count = t.cnt;

 

[Василий М.]

благодарю!

 

[NikSestrin]

На этапе проектирования лоханулся.
Есть таблица объявления, есть таблица изображения, содержащие ID объявлений.
Нужно в таблице объявлений сделать поле кол-во_изображений.
Как проапдейтить таблицу без PHP? Чисто средствами SQL?

Подход неправильный. Есть правило, которое гласит - не хранить в таблице то, что всегда можно расчитать, имея исходные данные.
Вот если одно поле содержит число 1, второе поле число 2. Ну и по Вашему нужно еще поле, которое будет содержать их сумму - 3. Как вы думаете - это правильно. Ведь всегда есть вероятность того, что значение 1 изменится на 2. А про поле со значением 3 забыли. И получится, что 2+2=3. Вот и облом наступит. А если хранить результаты серъезных бизнес-процессов...?

 

[Gas]

NikSestrin
есть теория, а есть практика, и при понимании плюсов и минусов денормализации - можно её использовать.

 

[NikSestrin]

NikSestrin
есть теория, а есть практика, и при понимании плюсов и минусов денормализации - можно её использовать.

Согласен. Конечно каждый волен поступать как ему видится правильным. Но я не понимаю, вот с чисто практической точки зрения. Вот добавится в таблицу изображений очередная картинка к объявлению. Нужно значит каждый раз апдейтить таблицу объявлений. Вопросов нет - все это можно сделать. Это можно зделать например в триггере таблицы изображений. Но ведь это можно сделать и менее затратным способом, с меньшим количеством телодвижений, не отходя далеко "от науки", ИМХО.
Если кого обидел - прошу прощения.

 

[Welcome]

Подход неправильный. Есть правило, которое гласит - не хранить в таблице то, что всегда можно расчитать, имея исходные данные.
Вот если одно поле содержит число 1, второе поле число 2. Ну и по Вашему нужно еще поле, которое будет содержать их сумму - 3. Как вы думаете - это правильно. Ведь всегда есть вероятность того, что значение 1 изменится на 2. А про поле со значением 3 забыли. И получится, что 2+2=3. Вот и облом наступит. А если хранить результаты серъезных бизнес-процессов...?

Расстояние между 2-мя какими-то статическими точками, тоже лучше каждый раз пересчитывать? Или из примера ТСа база с парой миллиардов картинок, дергать каждый раз пересчет или просто 1 раз вызвать триггер при изменении и обновить 1 колонку?

 

[Gas]

если выводится небольшой список объектов, и у них есть связанные сущности и которых в 99% случаев не более 10-20, то я бы динамически считал. А если этих связанных сущностей может быть много, то зачем cpu и диски греть.
Но в любом случае, всё индивидуально, для начала лучше делать всё по правильному.

 

[NikSestrin]

Расстояние между 2-мя какими-то статическими точками, тоже лучше каждый раз пересчитывать? Или из примера ТСа база с парой миллиардов картинок, дергать каждый раз пересчет или просто 1 раз вызвать триггер при изменении и обновить 1 колонку?

Да согласен, спору нет, триггер нас спасет (см. предыдущий мой топик). Просто из поста ТС видно, что триггера нет, вот я и ...