Хранение в базе неограниченного кол-ва картинок с описаниями

trashcan

Новичок
Структура базы для хранения неограниченного кол-ва картинок

Пишу каталог для CMS, столкнулся с проблемой выбора оптимального решения:
Есть две таблицы (заполнил для примера).

PHP:
=field_types=
id  |  name
---------------
1   |  textarea
2   |  images

=fields_values=
id  | page_id | field_type_id |  value
---------------------------------------------------
1   |   1     |      1        |  Какой-нибудь текст
2   |   1     |      2        |  image
Сложности возникли с полем типа images, так как этот тип предполагает хранение неограниченного кол-ва картинок, кроме того для каждой картинки должно быть предусмотрено описание. Поэтому вариант первый:

Хранить имена картинок в разных строках таблицы fields_values, но с одинаковым field_type. То есть так:
PHP:
=fields_values=
id | page_id | field_type |  value
------------------------------------------------
1  |   1     |     1      |  Какой-нибудь текст
2  |   1     |     2      |  image1
3  |   1     |     2      |  image2
4  |   1     |     2      |  image3
Описания в таком случае хранятся в таблице images с такой структурой:
PHP:
=images=
desc        |  fields_values_id
--------------------------------
Some_desc1  |         2
Some_desc2  |         3
Some_desc3  |         4
Тогда для вывода нужно сделать запрос на получение всех value и field_type для определенного page_id, а потом каждый раз когда встречается тип "images" делать запрос к таблице images и получать описания, то есть сколько картинок, столько и отдельных запросов.

Второй вариант - хранить в fields_values только одну запись для всех картинок, а сами значения хранить в таблице images:
PHP:
=fields_values=
id | page_id |  field_type |  value
-------------------------------------------------
1  |    1    |     1       |  Какой-нибудь текст
2  |    1    |     2       |  NULL
PHP:
=images=
id  |  value   |    desc      |  fields_values_id
-------------------------------------------------
1   |  image1  |  Some_desc1  |         2
1   |  image2  |  Some_desc2  |         2
1   |  image3  |  Some_desc3  |         2
Казалось бы данный вариант лучше, так как одним запросом выдергивает все картинки с описаниями, но есть одно НО, а именно должно выполняться условие, что если какой-то из разделов каталога (который может быть страницей, но все равно содержать подразделы) не заполнен инфой, то должна отображаться инфа дочернего, поэтому выборка всех полей страницы идет по условию IS NOT NULL и в этом варианте картинки (даже если они загружены) будут продинамлены.

Далее моего воображения хватило на следующее:
- либо хранить в поле value таблицы fields_values текущее число картинок для конкрентного page_id, содержащихся в табл. images, и добавить к выборке полей условие "если тип=images и value!=0". Тогда каждый раз при удалении или добавлении картинок придется делать запросы на модификацию и этого поля тоже.
- либо оставить NULL и добавить в условие выборки подзапрос, который для типа images проверял бы кол-во записей в таблице images c требуемым value_id.

В общем-то, вопрос такой: какой из этих вариантов и подвариантов более здравый? Или может есть более адекватные пути?
Заранее благодарю всех, кто ответит, ну или хотя бы дочитает до конца :)

-~{}~ 22.10.07 16:21:

Может хоть скажете, что мне сделать с моим вопросом, чтобы все таки получить на него ответ.
А то у меня складывется впечатление, что для этого надо использовать хитроумную тактику: сначала написать коротко и невнятно, а потом, после фразы "Ясновидящих здесь нет" уже объяснять подробно. По крайней мере у других так прокатывало.
 

Фанат

oncle terrible
Команда форума
вопрос задан невнятно.
начинаем про картинки:
одним запросом выдергивает все картинки с описаниями
вроде бы - обычная задача.
но тут резко уходим в сторону ДЕРЕВА:
но есть одно НО, а именно должно выполняться условие, что если какой-то из разделов каталога (который может быть страницей, но все равно содержать подразделы) не заполнен инфой, то должна отображаться инфа дочернего
какая связь между содержимим каталога (картинками) и его структурой (структурой), никто не понял.

плюс ко всему, радость в виде классической "Универсальной Базы Для Всего Во Вселенной".

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

trashcan

Новичок
Спасибо за ответ, так уже лучше.

Автор оригинала: *****
но тут резко уходим в сторону ДЕРЕВА:

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

плюс ко всему, радость в виде классической "Универсальной Базы Для Всего Во Вселенной".

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

Ладно, попытаюсь тогда объяснить проще и насколько это возможно без абстракций. Ну и не буду забегать вперед:
Для хранения имен картинок лучше завести отдельную таблицу, я правильно понимаю? Или все таки хранить их вместе со значениями остальных полей?
 

Фанат

oncle terrible
Команда форума
честно говоря, я не очень разобрался в структуре твоей базы, и поэтому вопроса не понял.
отдельно от каких именно полей? полей, относящихся к картинке или к абстрактной записи?
 

trashcan

Новичок
даже не знаю как объяснить
Почему запись должна быть абстрактной. Пусть она будет типовая, предположим на этой странице должна содержаться информация о каком-либо товаре и будут фиксированные редактируемые поля: Наименование типа text, Модель типа text, Тех. характеристики типа textarea, Наличие типа checkbox, Фото типа file.
Ессно, что хранить значения всех этих полей надо в отдельных записях. Я храню их всех в одной таблице.
Так вот имена картинок и описания к ним получается надо хранить в дополнительной таблице? Или имя хранить в основной, а описание в дополнительной?
 

Фанат

oncle terrible
Команда форума
но фотографий же может быть больше, чем одна?
значит, для фотографий должна быть отдельная таблица
 

trashcan

Новичок
да, фотографий может быть сколько угодно

а эта отдельная таблица должна быть как то связана с той таблицей, где хранятся поля другого типа?
 

trashcan

Новичок
то есть в таблице, где хранятся обычные поля, должна быть ОДНА запись, которая будет связана отношением один-ко-многим с картинками из доп. таблицы, правильно?
 

trashcan

Новичок
а если мне понадобится проверить на пустоту все поля страницы, включая поля с картинками (чтобы знать есть ли на странице хоть какая-то информация) мне придется писать либо два запроса, либо один но с подзапросом к таблице images?
 

trashcan

Новичок
ладно, в общем, главное я уяснил - картинки в отдельной таблице, с остальным как-нибудь разберусь
Еще раз спасибо.
 

Gas

может по одной?
trashcan
я не углублялся в изучение структуры твоей базы, но почему бы для начала не посмотреть на похожие темы
 
Сверху