Порядок фотографий в галерее

[DELPHIna]

Вот возник такой вопрос как же лучше и правильнее сделать?

Есть фотогалерея (в бд табличка типа:
- id
- name(описание фотки)
- ordery (порядок фотки в галерее)
- id_gallery (к какой галерее офтка относится)

у меня сделано так: что все фотки нумеруются хоть от 1...до N, хоть все вначале имееют номер N....
а потом User меняеет как ему надо , кому 1,2,3.... и фотки выводятся в галерее как ему угодно

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

вообщем нужно как то их более уникально что ли по порядку ставить.

Слышала что нужно как то уникально задавать номер(ordery) в пределах галереи, но при удалении фотки сдвигаться же будут все номера??? А может ещё как???

Посоветуйте что нибудь? Может есть уже готовый палгоритм решения...или кто то сам что то делал???

Очень нуждаюсь в совете, примере.

[null]

Иными словами Вам нужен список
Храните в записи о фотке номера предыдущей и следующей фоток (если список нужен двунаправленный: т. е. по одной записи Вам надо искать как предыдущую так и следующую), только предыдущей или только следующей (если однонаправленный: тут выбор зависит от алгоритма но вобщем пофиг ссылку на кого хранить) Ну и для каждой коллекции придется хранить как минимум голову списка. Т. е. в итоге Вы поимеете две таблицы: таблицу коллекций, хранящую номера голов списков, названия колеекций и проч., и таблицу фоток, хранящую сведения о фотках и, для каждой фотки, ссылку на соседа. Концевые фотки одну из сцылок (или единственную, в случае с однонаправленным списком) имеют в NULL.
Все просто.

ps: по большому счету пофиг какой одно или двунаправленный список Вы используете. Или, например циклический (ноги ссылаются на голову). Это скорее вопрос удобства, сокращения размеров БД, поиска в БД или времени работы скрипта.

[DELPHIna]

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


кстати мне фотки что каждый раз нумеровать? т.е. в галереи уже есть куча фоток.... но параметр ordery уних не по порядку....не от 1....N
мне его пронумеровать ещё надо, и каждую новую фотку при вставке нумеровать N+1 так ведь???

что то не варит голова сегодня ваще

[Aykroyd]

null
Вопрос:

А разве нельзя просто нумеровать фотографии, например, через 10... Или 20... ? А потом по этому полю их сортировать при выводе. Если же понадобится вставить что-то "в середину", можно, например, назначить номер 16. Конечно, не совсем универсальный способ. ))

(я вполне могу заблуждаться, не особо силен в БД, прошу отнестись с пониманием и разъяснить )

[DELPHIna]

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

я как то придумала уже....но точно не оптимально

вообщем если фотки идут так:
1,2,3,4,5,6

и я хочу вставить фотку в позицию 3 ...то я сделала так...что начиная от позиции 4 все смещаются на 1 значение(ordery+1) в конец и сортируются от 4,5,6,7 , не на позицию смещаются а по порядку

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

а списками динамическими.....как то навороченно кажется

[Aykroyd]

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

Я делал поправку, что предлагаемый мной способ не является универсальным.

[null]

Aykroyd, вот из-за таких как ты все зло в мире и происходит ... "просто нумеровать"... ты когда-нибудь писал на младших версиях бейсика? никогда строки перенумеровывать не приходилось?..
DELPHIna, решение со списком вовсе не сложное. это только так кажется. Фукнции для работы со списком элементарные — это же учебное задание дают детишкам чуть не в школе. Этот список ничем от того не отличается. То, что делаете вы на больших коллекциях фоток неоправданно нагружает сервер БД. Если можно писать красиво почему бы не писать красиво

Я бы сделал так
Таблицы имеют следующий вид
gallery
id // идентификатор, первичный ключ, unsigned tinyint (255 галерей хватит)
title // имя, varchar(50)
description // описание галереи, tinytext или varchar(255) (в зависимости от того что для вас первично — быстродействие или размеры базы; 255 символов для описания имхо вполне достаточно)
head // ссылка на голову списка — id первой фотки из списка в таблице photo

photo
id // идентификатор, первичный ключ, unsigned smallint (65000 фоток в галерее достаточно?)
name // название фотки, varchar(50)
description // описание фотки, tinytext или varchar(255)
prevouse // сцылко на предыдущий элемент (id предыдущего элемента; у головы NULL)
next // сцылко на следующий элемент списка (id следующего элемента; у хвоста NULL)
gallery // идентификатор записи в таблице gallery - это не обязательно, но просто для удобства работы с галереей в целом.

Интерфейс к галерее надо писать так, чтобы можно было просматривать все фотки с фильтрами по любому из полей (кроме id, prevouse и next конечно) — здесь это делается элементарно. извлекать фотки галереи в нужном порядке (один запрос выбирающий все фотки галереи, а затем обработка результата; но, при отсутствии поля gallery можно и серией запросов), создавать галереи (легко и просто — новая запись в gallery), добавлять и удалять фотоки в/из галереи, их сортировка там (тоже просто — элементарные функции работы со списком).

PS: Никакое поле ordery Вам вообще не нужно. оставте его в покое до тех пор, пока не станет понятно, что ваш новый код работает и его, это поле, можно удалить.

[Aykroyd]

Originally posted by null@Mar 21 2007, 19:28
ты когда-нибудь писал на младших версиях бейсика? никогда строки перенумеровывать не приходилось?..* *
<div align='right'>[Только зарегистрированные пользователи могут видеть ссылки. ]

[/quote]
Приходилось. Начинал со встроенного Бейсика на ZX Spectrum в 1990-ом году. Потом был GWBasic на IBM PC/XT, потом Turbo Basic и QBasic на первых эйтишках...

Originally posted by null@Mar 21 2007, 19:28
Aykroyd, вот из-за таких как ты все зло в мире и происходит ...* * "просто нумеровать"...
<div align='right'>[Только зарегистрированные пользователи могут видеть ссылки. ]

[/quote]
Я видел, что было до корректировки твоего сообщения. Боюсь, что в следующий раз не успеешь вовремя очередной свой пост откорректировать... ))

Ведь попросил объяснить по-человечески и специально откомментил: "я вполне могу заблуждаться, не особо силен в БД, прошу отнестись с пониманием и разъяснить". Ан нет. В ответ – 90% эмоций и LOL... Грустно. Что ж, возьму на заметку...

[Scorched.dn.ua]

DELPHIna, идея в принципе правильная, я только не очень понял что ты там сортируешь )) при добавлении фотографии под номером N в базу выполняем следующие запросики

UPDATE t SET ordery=ordery+1 WHERE ordery>=N
INSERT INTO t ( id , name , ordery , ... ) VALUES ( ... , ... , N , ... )

т.е. буквально в две строчки подвигаем элементы и вставляем в середину новую фотку средствами SQL.

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

на Айкройда не наезжай -- он старается помочь ))))))))))

[null]

Scorched.dn.ua, за этими двумя строчками crhsnf напряженная работа MySQL.
Где там усложнение кода и снижение скорости работы? Объясняй

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

$result = mysql_query("SELECT * FROM photo WHERE id=$id");
$current = mysql_fetch_array($result);
$result = mysql_query("INSERT INTO photos ( title, description, prevouse, next, gallery ) VALUES ( $title, $description, $id", ".$current[&#39;next&#39;].", ".$current[&#39;gallery&#39;] );
$result = mysql_query("UPDATE photo SET next=LAST_INSERT_ID() WHERE id=$id");
$result = mysql_query("UPDATE photo SET prevouse=LAST_INSERT_ID() WHERE id=".$current[&#39;next&#39;];

[Korn]

null
вместо двух полей prevouse и next, гораздо проще добавить одно order
в чем выигрыш ты объяснил на уровне
"Выигрыш в том что нет нумерации, в том что нет нумерации" и про какойто бейсик.

в случае с ордером у нас тоже в случае перемещения изменения двух записей, а в случае с добавлением, всетавка одной новой.

а вот чтоб добавить новую запись твои методом
нужно вычислить последнюю запись, добавить новую запись, потом получить id новой записи, и изменить старую последнюю запись.

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


$result = mysql_query("SELECT * FROM photo WHERE id=$id");
$current = mysql_fetch_array($result);
$result = mysql_query("INSERT INTO photos ( title, description, prevouse, next, gallery ) VALUES ( $title, $description, $id", ".$current[&#39;next&#39;].", ".$current[&#39;gallery&#39;] );
$result = mysql_query("UPDATE photo SET next=LAST_INSERT_ID() WHERE id=$id");
$result = mysql_query("UPDATE photo SET prevouse=LAST_INSERT_ID() WHERE id=".$current[&#39;next&#39;];

во много раз сложнее чем
$result = mysql_query("INSERT INTO photos ( title, description, order, gallery ) VALUES ( $title, $description, time(), ".$current[&#39;gallery&#39;] );

[Scorched.dn.ua]

_Korn в принципе понял, постараюсь чуть детальнее объяснить почему так делать не стоит.

Алгоритмическая сторона

1. Возьмем готовую таблицу, организованную описанным тобой образом, состоящую к примеру из 100 записей. И тут юзер хочет вставить фотографию например под номером 55. Если ты при этом не используешь "нумерацию", твоему скрипту придется вначале вычислять куда её конкретно вставлять -- т.е. по сути пробегать с 1го элемента, до 55го (ну или с конца - неважно), выполняя для каждого по 1 запросу -- в чем же в итоге оптимизация?? вы при своей вставке выполнили N запросов возвращающих по 1 строчке, а я 1 запрос, изменяющий N строк.

2. Ты можешь предложить вариант: "А я возьму, действительно довалю order к своему динамическому связанному списку, и организую дин. структуру vector". Кстати напомню, что именно vector ускоряет вставку в середину, но никак не обычный list. Но даже используя такую структуру, вам все равно при добавлении нового элемента придется изменять счетчики для всех тех, которые идут после него

Практическая сторона

1. А теперь давай не будем забывать, что у нас тут не массивы с указателями, а всего лишь таблица из БД. И один запрос работающий с сонтей строк отработает на порядок быстрее, чем сто запросов, каждый из которых работает с одной строкой. Только что касается моего запроса, то mysql специально оптимизирован именно для подобных простых запросов, пробегающих разок по всей таблице. А вот поиск 1й записи в таблице с данным индексом, её придется именно искать, т.е. перебирать несколько записей, для каждого такого запроса

2. А теперь тривиальная задача вывода всех фоток, которая происходит намного чаще, чем вставка фотки )) Для того чтобы вывести поочередно фотки, вместо одного "большого" запроса "select from.. order by..." тебе придется опять же выполнять кучу "маленьких" -- по одному для каждого элемента. Еще раз повторюсь "большой" будет выполняться лишь ненамного дольше, чем "маленький".

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

[null]

_Korn, и фотки, зачем-то, упорядочены по дате и времени добавления. Ну что вы будете потом с этим временем делать? Как изменить их порядок?

[DELPHIna]

ндаааа....я точно пошла по пути который описал Korn....а надо наверное по пути null....

ксатти галерея у меня специфичная...нет там сортировки по времени...там времени у фотки вообще нет: выводится всё просто таблицей NxM и всё....и чаще всего нужно не вставлять фотку в середину например, а менять местами те, что уже есть... поменять местами 10 и 5, 18 сделать 1 и так далее.... вставка новой в середину куда реже происходит...

Спасибо...попробую со списком этим....

P.S. а кто то уже делал что то подобное???

[null]

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]_Korn в принципе понял, постараюсь чуть детальнее объяснить почему так делать не стоит.

_Korn&#39;у я ответил. Либо я не понял, что он имел ввиду, либо то, что он имел ввиду - чушь, либо он сам не понял, что он имел ввиду Надеюсь, что неправ я

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]1. Возьмем готовую таблицу, организованную описанным тобой образом, состоящую к примеру из 100 записей. И тут юзер хочет вставить фотографию например под номером 55. Если ты при этом не используешь "нумерацию", твоему скрипту придется вначале вычислять куда её конкретно вставлять -- т.е. по сути пробегать с 1го элемента, до 55го (ну или с конца - неважно), выполняя для каждого по 1 запросу -- в чем же в итоге оптимизация?? вы при своей вставке выполнили N запросов возвращающих по 1 строчке, а я 1 запрос, изменяющий N строк.

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

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]2. Ты можешь предложить вариант: "А я возьму, действительно довалю order к своему динамическому связанному списку, и организую дин. структуру vector". Кстати напомню, что именно vector ускоряет вставку в середину, но никак не обычный list. Но даже используя такую структуру, вам все равно при добавлении нового элемента придется изменять счетчики для всех тех, которые идут после него

Нет, я не буду это предлагать По указанной причине.
Вектор ускоряет поиск, а не вставку.

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]1. А теперь давай не будем забывать, что у нас тут не массивы с указателями, а всего лишь таблица из БД. И один запрос работающий с сонтей строк отработает на порядок быстрее, чем сто запросов, каждый из которых работает с одной строкой. Только что касается моего запроса, то mysql специально оптимизирован именно для подобных простых запросов, пробегающих разок по всей таблице. А вот поиск 1й записи в таблице с данным индексом, её придется именно искать, т.е. перебирать несколько записей, для каждого такого запроса

Для того, чтобы ничего не перебирать в бд существуют индексы. Кстати в MySQL для первичных ключей они создаются автоматически. Так что поиск записи по первичному ключу - операция очень быстрая (вектор, ага )
Возможно MySQL действительно оптимизирован под такие запросы. Этого не знал. Где об этом можно прочесть подробнее?
Впрочем если не хочется растить трафик между web и mysql серверами, то можно оформить функции работы со списком в виде хранимых процедур. MySQL 5 это уже умеет.

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]2. А теперь тривиальная задача вывода всех фоток, которая происходит намного чаще, чем вставка фотки )) Для того чтобы вывести поочередно фотки, вместо одного "большого" запроса "select from.. order by..." тебе придется опять же выполнять кучу "маленьких" -- по одному для каждого элемента.* Еще раз повторюсь "большой" будет выполняться лишь ненамного дольше, чем "маленький".

Вот это суровый аргумент Думаю здесь тоже стоит сделать хранимую процедуру... Хочу проверить. Давай проверим? Сделаем галереи На MySQL > 5 и php5 (ну можно и на 4). Есть время?

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]Вывод: БД предоставляет нам кучу возможностей, надо которыми разработчики парились годами, оптимизируя их, давая возможность конечному программеру просто использовать их не заморачиваясь с придумыванием своих способов хранения и пр., нужно стремиться к простоте

Нужно стремиться к эффективности. Написать 4 строки вместо одной не так уж сложно.

зы: Я тут столкнулся с такой вот программой, где порядок указывается вручную циферкой. Это ужастно...

[null]

DELPHIna, какая у вас бд? MySQL? Какя версия?

[DELPHIna]

null, MySQL 4.1.10a - это на сервере....а я ещё локально собираю обычно....у ся дома...а потом выкладываю на сервер, дома 4.1.9 а отчего такой вопрос?...заинтересовали

[Korn]

Originally posted by null@Mar 22 2007, 10:14
_Korn,* и фотки, зачем-то, упорядочены по дате и времени добавления. Ну что вы будете потом с этим временем делать? Как изменить их порядок?*
<div align='right'>[Только зарегистрированные пользователи могут видеть ссылки. ]

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

[null]

DELPHIna, MySQL 4 кажется еще не умеет хранить процедуры. Так что выборка списка превратится в многие запросы к базе
_Korn, ясно. хоршая идея.
DELPHIna, ну черт его знает... Если в ordery хранить время (случайное число), то придется перебором искать нужный элемент при вставке фотки между двумя другими. Это тоже серия запросов. но зато выборка с сортировкой значительно быстрей, чем у списка. А это таки самая частая операция, как ни крути. Так что можно сделать и так, как предлагает дяденька _Korn

Бывает еще кэширование. Например с помощью могучей функции ob_start(). Такой метод лечит основной недостаток списка — медленную выборку, а вот алгоритму с ordery не поможет никак...

[Korn]

null
если надо вклинить между двух,
то поулчаем ордеры этих двух (1 запрос), если их разница больше 1 берем среднее значение из этой разницы, и ставим выбранному это значение( + 1запрос ).
если разница равна 1, меняем все ордеры больше первого на order=order+1 ( 1 запрос ), и ставим ордер второго, выбранному ( 1 запрос )

итого 3 запроса макисимум, в очень редком случае. в остальных, два