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

count id in table

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 или чё та типа того...

Вопрос: как это сделать?
 

Mammoth

Guest
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 | <прочая_информация_о_комментарии>
 

mahoune

Guest
Mammoth, помоему с таблицей у него все нормально! :)
SELECT COUNT(ID) as comm_quant, author_id, poem_id
FROM comments
GROUP BY author_id, poem_id
 

chira

Новичок
Mammoth:
Избыточность данных если она сделана осмысленно - не трагедия (это фича). И не обязательно сразу избавляться от этой избыточности.
 

Mammoth

Guest
2 Mahoune & Chira:

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

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

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

или SELECT COUNT(poem_id) FROM reply GROUP BY poem_id
 

Mammoth

Guest
> Теоретик, у тебя еще все впереди.

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

Кстати, от знания теории никто еще не страдал. Да и избыточность данных (даже если она сделана осмысленно) - это не фича, а наличие скрытых багов, разросшаяся база и геморройное программирование.
 

mahoune

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

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

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

Mammoth

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

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

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

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

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

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

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

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

ЗЫ. Mahoune, мы с тобой не ругаемся. Успокойся. Не воспринимай все так близко к сердцу. В главном я с тобой согласен - каждый пишет так как ему удобнее. И я не пытаюсь навязать кому-либо свою точку зрения.
 

mahoune

Guest
Да я и не ругаюсь! :) Вообще не люблю ругаться! Просто человек может не понять, что следовать на 100% книжке не есть хорошо! Должно быть внутренее чутье и опыт! :)
 

chira

Новичок
Автор оригинала: Mammoth
> Теоретик, у тебя еще все впереди.
Как мне расценивать твою фразу? ;-)
Нажмите для раскрытия...
Сначала придерживаясь теории, мы нормализуем все данные, потом исходя из реальной ситуации, можем часть из низ денормализовать. (обеспечить нужную нам сортировку, для уменьшения JOINов в запросах, упростить запросы и тем самым ускорить их выполнение ...)
Кстати, от знания теории никто еще не страдал.
Нажмите для раскрытия...
согласен
 

Mammoth

Guest
Сначала придерживаясь теории, мы нормализуем все данные, потом исходя из реальной ситуации, можем часть из низ денормализовать. (обеспечить нужную нам сортировку, для уменьшения JOINов в запросах, упростить запросы и тем самым ускорить их выполнение ...)
Нажмите для раскрытия...
Надо понимать это ответ на мой вопрос?

ЗЫ. Chira, почему бы все же не почитать теорию?
 

Mammoth

Guest
Да я вообще-то теорию в универе изучал. На нескольких курсах. Преподов могу сказать. ;-)

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

R00miss

Guest
to Mammoth:

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

R00miss

Guest
Если подробнее:
есть база 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

во.. :)
 

Mammoth

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

Mammoth

Guest
to R00miss:

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

У тебя точно с ними не все нормально. И мне это не кажется. Но навязывать свое мнение не буду.
 

mahoune

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

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