Есть вот такая задача 8 похожих типов страниц с небольшим отличием у каждого типа есть два варианта картинок, прев и основное разного размера у каждого типа страниц эти размеры разные, где то квадрат, где то не прямоугольник, в паре типов вообще не фиксированный размер, а разнопляшущие размеры. мне нужно эти размеры как то прописать, что бы программно делать ресайз (через настройки сайта в админе). index.php?pagetype=1(2,3,4,5..8)[&page=219] если не выбрана конкретная страница, вываливаем список с превьюшками, и эти превьюшки разные. Нужно из базы выбрать размер соответствующий типу страницы и конвертить. (я пока пишу, тут же соображаю, может допишу и придет озарение ))) так вот засада как раз в типе разнопляшущих если для типа 1 допустим размер 250х250, для 2 250х300, вот как разнопляски записать для типа 7, чето не приходит ничего в голову и самое главное, как правильно по таблицам это раскидать? еще кроме превьюшек же и основное фото есть, которое тоже размеры разные таблица pic - id, parent, size-type таблица pic_size - size-type, size-val ? (озарение не пришло)
В таблице страниц поле для привязки к размерам, type_pic_id И таблица с всевозможными размерами id size_x size_y description.. и другие доп поля -не обязательные
ну это как бы да, но только момент к статье может отниситься от 3х до 5 разных картинок (и размеров) в зависимости от превью, основная, лента, и тп. добавить еще табличку с ключом по типу? small, big, thumb, caruselle и тп
@SibBear, не надо валить всё в одну кучу тип и страница совершенно разные сущности. Первой странице соответствует один тип, а седьмой странице соответствует несколько типов (а не один разнопляшущий тип)
так я об том и говорю, что не могу сложить в голове как сие должно правильно выглядеть и уж тем более в одну кучу не хочу, но и плодить сотню таблиц тоже не охото, потом голову сломаю где что если разносить на каждый тип страниц свой набор таблиц... таблица страница - ид, имя, тип страницы таблица типы сраниц - ид, тип, название типа (для себя и конфига) таблица картинка - ид, ссылка, родитель таблица размер для конверта - ид, размер таблица соотношения тип картинки/тип страниц - ид, идкартинки, размер ид, тип (маленькая/большая/превьюшка/тп) чет каша какая то если одна и та же картинка может быть в разных размерах, а другая только в одном размере, то логично в отдельную таблицку выносить это соотношение
одна таблица - содержит идентификаторы строк других таблиц, для связи. все другие для заполнения Типы - одна таблица Размеры - другая Все это join & group_concat делается
@SibBear, тебе надо разбить задачу на мелкие подзадачи и решать их в отрыве друг от друга. Начни с размеров фотографий. Название таблицы: sizes s_id - идентификатор строки (примари, автоинкремент) s_width - ширина (целое число) s_height - высота (целое число) теперь таблица страниц Название таблицы: pages p_id - идентификатор строки (примари, автоинкремент) p_name - имя страницы Теперь определи отношение между ними. Одна страница может содержать несколько размеров фотографий. Один размер может принадлежать нескольким страницам. Отношение pages - sizes - многие-ко-многим Поэтому создаём таблицу связи Название таблицы: page_size ps_id - идентификатор строки (примари, автоинкремент) p_id - идентификатор страницы s_id - идентификатор размера (тут можно обойтись без ps_id повесив первичный ключ на два поля p_id и s_id, но думаю с ps_id тебе будет пока проще) Вот и получилась твоя так называемая таблица типов станиц В админке ты выбираешь страницу и видишь доступные размеры, можешь удалять и добавлять их. Теперь надо определиться от чего зависит в какой размер конвертировать конкретное фото на конкретной странице, если на странице доступно много размеров.
db_page - page_id, name, page_type db_pic - pic_id, pic_name db_pic_parent - id, pic_id, parent_id db_pic_size - id, pic_id, size_id db_pic_size_use_where - id, pic_id, size_id, use_where db_cfg_pic_size - size_id, size_val db_cfg_page_types - id, page_type db_cfg_use_where - id, use_where (превью, карусель, большая и тп) вот что получается пока. что не так в структуре? @MouseZver, в курсе я про join, спасибо. --- Добавлено --- разбивал, вообще зарылся )))
Стоп, еще раз перечитал твоё сумбурное первое сообщение, кажется начинаю догадываться о чём речь. добавляешь таблицу types t_id - идентификатор строки (примари, автоинкремент) t_name - имя типа (preview, base и тд.) И добавляешь тип в уже имеющуюся таблицу связи, только меняешь название на page_type_size pts_id - идентификатор строки (примари, автоинкремент) p_id - идентификатор страницы (уникальное поле) t_id - идентификатор типа (уникальное поле) s_id - идентификатор размера (уникальное поле) Угадал?
В итоге все получилось на первом этапе. На втором пришлось чуток пакость сделать ))) дело в том, что картинки раскиданы по разным папкам для удобства, от типа страницы. Одна картинка может использоваться в разных назначениях как все выше описано. Путь с сайта к картинке спрятан в md5. Теперь что бы обратный путь проделать от md5 картинки и найти исходник целая эпопея ))) добавил в начало имени три цифры, что бы распарсить по ним путь к исходной картинке после того как в базе нашел нужную, а то не хватает данных иначе. Не хотел путь делать по типу upload/size/type/md5(pic).jpg сделал upload/123md5(pic).jpg костыль, но пока не придумал как иначе )) Всем спасибо!
я пользователю показываю поддельные имена картинок, и путь к ним upload/sabfw8fhwnfl83urfi72ujbed73ir.jpg
это пока временно, потом там будет чпу'шное название, но их так много, что в ручную переписывать имена исходных файлов оч не хочется