Меню
Что нового?

count id in table

  • Автор темы Автор темы R00miss
  • Дата начала Дата начала

R00miss

Guest
count id in table

Привет снова!
Вообщем есть таблица comments в ней: id | author_id | poem_id | comment

Нада: посчитать сколько id у каждой poem_id в author_id и показать :)

Подробнее: есть автор (author_id) у него есть стих (poem_id), и нада показать сколько комментариев всего у этого стиха, т.е. нада посчитать poem_id принадлежайщей author_id или чё та типа того...

Вопрос: как это сделать?
 
R00miss, ИМХО у тебя имеются проблемы с теорией. Очень уж странная структура таблицы. По-моему, она требует нормализации, так как она страдает избыточностью. Т.е. менять надо структуру всей базы.

По поводу нормализации:

1. Что такое id? Уникальный ключ, определяющий комментарий?
2. У тебя что, - имеются поэмы (стихи) с одним poem_id но с разными авторами? Именно с разными, а не с несколькими.

Предлагаю тебе подумать над следующей структурой:

poets:
poet_id | <информация об авторе>

// предусматриваем вариант авторства несколькими поэтами
authors:
poet_id | poem_id

poems:
poem_id | content

reply:
poem_id | comment_id

comments:
comment_id | comment_content | <прочая_информация_о_комментарии>
 
Mammoth, помоему с таблицей у него все нормально! :)
SELECT COUNT(ID) as comm_quant, author_id, poem_id
FROM comments
GROUP BY author_id, poem_id
 
Mammoth:
Избыточность данных если она сделана осмысленно - не трагедия (это фича). И не обязательно сразу избавляться от этой избыточности.
 
2 Mahoune & Chira:

Вы хотя бы слышали о том, что требуется предварительное проектирование БД? Знакомы с теорией реляционных баз данных? В любом случае советую ознакомиться во избежание геморроя... ;-)

Кстати, в моем варианте решение было бы таким:

query="SELECT COUNT(*) FROM reply WHERE poem_id='".$poem_id."'";

или SELECT COUNT(poem_id) FROM reply GROUP BY poem_id
 
> Теоретик, у тебя еще все впереди.

Как мне расценивать твою фразу? ;-)

Кстати, от знания теории никто еще не страдал. Да и избыточность данных (даже если она сделана осмысленно) - это не фича, а наличие скрытых багов, разросшаяся база и геморройное программирование.
 
Не скажи! У меня было пару проектов! Все было построено по всем правилам нормализации! И что?! Когда дело доходило до того что-б вывести полную картину приходилось запрашивать данные из очень многих таблиц! :)

И что каксается книжек по реляционным БД, даже там всегда оговаривается, что нормализация никогда не должна переступать все грани! Если в поле заведомо будет хранитmcz всю жизнь ТРИ значения, нет смысла для этого делать таблицу с индексами и удаленными ключами! ;)

Одним словом в каждом отдельно взятолм проекте должен быть свой подход! Но он должен быть ярко обоснован!!!
 
> Когда дело доходило до того что-б вывести полную картину приходилось запрашивать данные из очень многих таблиц!

И в чем проблема?

> И что каксается книжек по реляционным БД, даже там всегда оговаривается, что нормализация никогда не должна переступать все грани!

Ну третья-то форма желательна!

> Если в поле заведомо будет хранитmcz всю жизнь ТРИ значения, нет смысла для этого делать таблицу с индексами и удаленными ключами!

При чем тут нормализация?

> Одним словом в каждом отдельно взятолм проекте должен быть свой подход! Но он должен быть ярко обоснован!!!

Я обосновал свой подход. Может правда не столь ярко, как тебе хотелось бы... ;-)

ЗЫ. Mahoune, мы с тобой не ругаемся. Успокойся. Не воспринимай все так близко к сердцу. В главном я с тобой согласен - каждый пишет так как ему удобнее. И я не пытаюсь навязать кому-либо свою точку зрения.
 
Да я и не ругаюсь! :) Вообще не люблю ругаться! Просто человек может не понять, что следовать на 100% книжке не есть хорошо! Должно быть внутренее чутье и опыт! :)
 
Автор оригинала: Mammoth
> Теоретик, у тебя еще все впереди.
Как мне расценивать твою фразу? ;-)
Нажмите для раскрытия...
Сначала придерживаясь теории, мы нормализуем все данные, потом исходя из реальной ситуации, можем часть из низ денормализовать. (обеспечить нужную нам сортировку, для уменьшения JOINов в запросах, упростить запросы и тем самым ускорить их выполнение ...)
Кстати, от знания теории никто еще не страдал.
Нажмите для раскрытия...
согласен
 
Сначала придерживаясь теории, мы нормализуем все данные, потом исходя из реальной ситуации, можем часть из низ денормализовать. (обеспечить нужную нам сортировку, для уменьшения JOINов в запросах, упростить запросы и тем самым ускорить их выполнение ...)
Нажмите для раскрытия...
Надо понимать это ответ на мой вопрос?

ЗЫ. Chira, почему бы все же не почитать теорию?
 
Да я вообще-то теорию в универе изучал. На нескольких курсах. Преподов могу сказать. ;-)

Правда, дома одна книжка валяется - если не забуду, завтра скажу кто автор. Но ты с тем же успехом можешь поискать в инете.
 
to Mammoth:

Спасибо конечно за таблицы, но мне тоже кажется у меня все нормально с ними...
 
Если подробнее:
есть база Poems
в ней три таблицы: Authors, Poems, Comments

в authors я храню все что к автору относится, в poems я храню id автора, стих, и все что к стиху относиться, но структура такая author_id, id т.е. допустим есть 2 автора, т.е.
получается:
author - 1, poem - 1
author - 1, poem - 2
author - 1, poem - 3
и author - 2, poem - 1
author - 2, poem - 1

т.е. id стихов не уникальные, поэтому мне нада посчитать сколько id comments пренадлижащие id poem принадлежащих id author

во.. :)
 
Тем кто все же интересуется теорией: могу рекомендовать книжку Конноли, Берга и Срачана (кажется, не напутал). Название: "Базы данных: проектирование, реализация и сопровождение. Теория и практика."
 
to R00miss:

> Спасибо конечно за таблицы, но мне тоже кажется у меня все нормально с ними...

У тебя точно с ними не все нормально. И мне это не кажется. Но навязывать свое мнение не буду.
 
R00miss, прав Mammoth. У тебя на лицо отношение author к poems many-to-many а соответственно и придется делать как он предложил через дополнительную таблицу

authors:
poet_id | poem_id
 
Войдите или зарегистрируйтесь для ответа.
Сверху