Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > СУБД, общие вопросы > Помогите с организацией БД и хранением фоток

Автор: Dmitry_177 28.11.2007, 00:51

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

Автор: Данкинг 28.11.2007, 01:09

Я в веб-дизайне ничего не понимаю, но с БД работаю много. Я бы сделал именно ссылку на картинку в базе. А новые файлы с картинками можно, к примеру, переименовывать для хранения на сайте, добавляя дату и время закачки.

Автор: Dmitry_177 28.11.2007, 01:34

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

Автор: Данкинг 28.11.2007, 01:42

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

Автор: Dmitry_177 28.11.2007, 01:54

Цитата

ИМХО если будет ОЧЕНЬ МНОГО фоток - долго грузиться будет.. Запросы то делать можно и работать будет.. Только вот сколько по времени.. Это ведь нужно по всем таблицам пробегать в поиске нужного номера пользователя.. Мой вопрос в этом и заключался, можно ли как-то подругому организовать БД, чтобы побыстрее грузилось.. smile

Автор: Данкинг 28.11.2007, 02:29

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

Автор: skyboy 28.11.2007, 02:43

конечно - общую для всех тематик таблицу делать. иначем как ты будешь собирать "все фотки пользователя"? динамически формировать sql низзя, количество категорий меняется... Значит, тебе придетсмя постоянно править запросы. Вдохновляет такое? Меня - нет. Кроме того, такие вещи, как "слить несколько категонрий в одну" или "выделить фото с категориями `Человек` и `Животное` в категорию `Алкоголики с домашними питомцами`" или "найти все фоты, у которых не указана категория" и т.п. будет делать одним запросом на базе одной таблицы. разве это не хорошо? а первоначальный вариант с N таблиц если и будет адекватным решением, то не в этой вселенной smile

Автор: Akina 28.11.2007, 08:58

Ну стандартная же задача.

Фоты хранятся на диске. В БД хранится путь к фотке, ее нынешнее имя (оно синтезируется при загрузке, например = ID записи о фотке в таблице фоток), ее исходное имя (разумно отдать ее при скачивании именно с тем именем, с которым ее загружали, не так ли?) и прочую инфу.

Категорирование фоток - типичная задача построения связи много-ко-много и решается созданием таблицы соответствий (ID фотки - ID категории).

Автор: Dmitry_177 28.11.2007, 21:06

Цитата

Фоты хранятся на диске. В БД хранится путь к фотке, ее нынешнее имя (оно синтезируется при загрузке, например = ID записи о фотке в таблице фоток), ее исходное имя (разумно отдать ее при скачивании именно с тем именем, с которым ее загружали, не так ли?) и прочую инфу.

Категорирование фоток - типичная задача построения связи много-ко-много и решается созданием таблицы соответствий (ID фотки - ID категории).

В принципе да.. Тогда тут встает немного другой вопрос.. При сохранении фотки на сервере уже нужно знать ID фотки.. Мы же пока не знаем какой будет ID фотки в новой записи в таблице.. Т.е. нужно сначала записать инфу к фотке в таблицу, потом выбрать ID фотки сравнив эту же записанную инфу.. Т.е. примерно так:

Код


INSERT INTO photoinfo (info, date, type) VALUES ('супер фотка', 28.11.2007, 'sport');
SELECT id_photo FROM photoinfo WHERE info='супер фотка' AND date=28.11.2007 AND type='sport';

Потом уже узнав ID фотки можно присваивать его фотке и сохранять ее на сервере..

Я придумал такую штуку.. Но мне не очень нравится этот механизм тем что только что записали инфу, и потом ее же ищем в таблице.. Может можно что-то получше придумать? У меня база MySQL если что.. Может там полезная функция есть какая.. Может кто знает?

Автор: Akina 29.11.2007, 08:58

Цитата(Dmitry_177 @ 28.11.2007, 22:06

)

Т.е. примерно так:

Единственный способ, который ГАРАНТИРУЕТ получение правильного ID. Кстати, я бы хранил в таблице TimeStamp, а не только дату...

Автор: intDex 22.12.2007, 05:37

тип данных BLOB.

Автор: Deniz 22.12.2007, 09:32

Dmitry_177, а СУБД какая, может и подскажут нормальный вариант возврата ID фотки.
Опять же на чем пишется web-морда? Можно в имя фотки ID сессии добавить или GUID. Вариантов много.

Добавлено @ 09:35
Кстати в

Код

SELECT id_photo FROM photoinfo WHERE info='супер фотка' AND date=28.11.2007 AND type='sport';

можно ограничиться IDUser + DateTime(если конечно фотки по одной добавляются, а не пакетом). В любом случае по этим полям будет индекс, возможно даже один составной типа (IDUser asc, FotoDateTime desc). В этом случае запрос отработает быстрее.

Автор: Anark1 22.12.2007, 23:38

Цитата(Akina @ 28.11.2007, 08:58)

Категорирование фоток - типичная задача построения связи много-ко-много и решается созданием таблицы соответствий (ID фотки - ID категории).

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

Код


INSERT INTO photoinfo (info, date, type) VALUES ('супер фотка', 28.11.2007, 'sport');

работать не будет. Хотя, по моему, автору темы достаточно связи один ко многим.
И запрос для связанных таблиц будет вроде

Код


SELECT p.id_photo id FROM p photoinfo, t type WHERE p.info='супер фотка' AND p.date=28.11.2007 AND tid=t.id AND t.type = 'sport';

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