Подскажите пожалуйста.

Имеется БД в MySQL. Есть таблицы

Блоги
Blog_id

Комментарии к ним
Blogcomment_id

Фотки
Photo_id

Комментарии к фоткам
Photocomment_id

В данный момент к каждому типу (блоги, фотки) идет своя таблица с комментариями.

Я хочу объединить комментарии для фоток блогов, т.к. они по сути полностью одинаковые (вообще имеются не и другие объекты БД с комментариями, но для примера это не важно) и добавить функционала.

Создал таблицу comments
В которой comment_id – id коммента
Group_id – id фотки или блога, к которым пишется комментарий.
И пришлось добавить еще type_id, 0 – комментарий к блогам, 1 – комментарий к фоткам.

Хочу поставить внешнюю связь между group_id и ( blog_id или photo_id).
По сути получается, в таблице должны быть две связи
1. Blog_id ->(group_id+type_id)
2. Photo_id->(group_id+type_id)


А вопрос такой: Могу ли я средствами мускула задать такие связи? Или нужно создавать в блогах и фотках еще поле type_id, чтобы была железная связь, гарантирующая целостность данных, т.е. чтобы нельзя было удалить фотку или блог без удаления комментариев?

MasterZiv, ООП на SQL мне пока не доступно.

А вот про два поля вопрос.
А если будут не только блоги и фотки, а еще десяток объектов, например, комментарии к пользователям, к объединениям и т.п.
Для каждого своё поле создавать? И это нормально будет?

MasterZiv, всё понял, спасибо.

[quot alex564657498765453]сперва наперво, надо было задаться вопросом, а зачем обьеденять таблицы коментариев???
похожи у тебя , и что? музыкальные форматы тоже похоже, и проигрываються у меня одним проигрываетелем, и мне не приходит в голову раз похожи, конвертировать все в один формат, и тебе думаю тоже.
[.quot]
не совсем удачное сравнение. можно было сравнить полностью одинаковые на бинарном уровне с разным расширением, было бы ближе.

alex564657498765453поэтому главный вопрос - а зачем обьеденять?

т.к. комментарии у всех объектов полностью одинаковые, то держать под каждый тип объекта свою таблицу, их все модифицировать, писать под них хранимки, мне кажется не верно. потом с каждым комментарием может быть связана информация об активности и т.п. тоже что ли в отдельную таблицу для каждого объекта загонять?

так я напишу один набор хранимок, будет одна таблица, из которой одной подпрограммой я буду получать массив, который буду загонять в смарти. конечно под каждый тип объекта придётся писать свои пхп процедуры, но от этого не уйти.

делать десять одинаковых таблиц, потом их все менять, дорабатывать, мне кажется не совсем верно. вот поэтому.

это не оптимизация, а унификация.

alex564657498765453, т.е. я так вижу ситуацию.