КЛУБ СТОКОВЫХ ФОТОГРАФОВ, ИЛЛЮСТРАТОРОВ, ВИДЕОГРАФОВ и ИИ-ШНИКОВ

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

завтра придет... я иногда угадываю.

Хочу уточнить, каким образом сейчас происходит сортировка фотографий на Лори?
Вопрос возник по следующей причине: я просто так решил прогуляться по разделам сайта, нажал "каталог -> люди", всего там около 1000 страниц с фотографиями людей. Пролистал первые 100 страниц не поленился. Своих фотографий с людьми там не обнаружил, хотя гружу я фотографии достаточно равномерно по времени, то есть не должно быть таких больших "пробелов". Потом я догадался посмотреть просто на номера фотографий, оказалось, что они отсортированы не по номеру, а как отсортированы - не ясно.
Если искать по ключевым словам, то возможен выбор "по новизне, по релевантности", здесь все ясно. Если же искать по каталогу, то каким образом упорядочено там все - не понимаю.
Кстати, касательно релевантности... либо я что-то пропустил, либо, как говорили в мультике, одно из двух. Откуда берется релевантность? Какая-нибудь секретная внутренняя формула?
И по поводу сортировки по новизне. Все не так просто как я думал. Хотел сделать простую вещь: мне известен номер фотографии, хочу отсортировать поиск по новизне и посмотреть, как далеко эта фотография уже убежала. Не получилось. Потому что новизна не совпадает с номером. Как я понимаю, номер дается при загрузке на сайт, а новизна, когда фотография принимается редактором. Отсюда и расхождение. Но тогда как-то с этим надо разобраться, как мне кажется. Сделать сортировку по дате, и по номеру. Хотя мне вообще кажется, что это излишнее усложнение и ИМХО лучше, чтобы новизна совпадала с номером фотографии.

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

P.S. Например, сколько бы это проблем на Шуттерстоке решило!

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

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

Тут сразу несколько моментов:

а) Длина любого отображаемого списка на Лори ограничена 12 тысячами картинок или 1000-ю 12-картиночных страниц. Поэтому если ваши картинки с людьми были приняты полгода назад, то при простом листании каталога «Люди» вы их не обнаружите (за это время туда попадёт всяко больше 12000 новых людей. Но поскольку всё равно никто не будет листать 1000 страниц, то это не страшно. А при поиске ваши картинки всплывут (если они соответстуют запросу).

б) Сортировка по умолчанию в каталоге и пр. происходит по дате приёма картинки. Номер картинки — это порядковый номер _загрузки_ в базу, а не номер _приёмки_, поэтому номера растут не монотонно при сортировке по дате приёма. Но отклонение от монотонности составляет в среднем не больше нескольких десятков номеров (хотя бывают, конечно, выбросы, если картинка долго гуляет по редакторам). Вторую нумерацию мы делать точно не будем, потому что она гарантированно запутает ВСЕХ, а польза от неё может быть только в очень специальных случаях. Всё-таки у нас несколько более предсказуемая приёмка, чем на Шаттере, при всём к нему уважении:)

в) Релевантность при поиске — это степень соответствия ключевиков+названия поисковому запросу. Никакие другие параметры (продаваемость и пр.) при этом не учитываются.

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

Ребята, не выдумывайте - всё решается гораздо проще, я бы даже сказал элементарно.
Кроме того в нормальной базе ИД (в частности "номер") это служебная информация, которая в общем-то может быть скрыта от конечного пользователя. В качестве ИД может использована любая уникальная информация, однозначно идентифицирующая объект. Т.е. номер(число) это частное решение UID, в основном используемое только для того, чтобы сократить объём занимаемый UID и для небольшого (очень) увеличения скорости выборки по ИД.


Ох уж эти программисты...

Посмотрим, посмотрим...

Скажите, а в связи с чем выплата с Коммерческая для полиграфии, A6 составляет 360 руб при цене продажи в 1200 руб, а Некоммерческая для полиграфии, А4 - 600 руб, при тех же 1200 рублях?
Другие цены тоже так пляшут. Я понимаю что цены и проценты авторских гонораров взяты не с потолка, но хотелось бы просто прояснить вопрос.

При продаже некоммерческой А4 за 600 р. автору начисляется 300р
При продаже коммерческой А6 за 1200 р. автору начисляется 360р.

на сайте есть вся вохможная информация.

Оно понятно, что искать ее не хочется...

http://lori.ru/doc/forauthors/faq#сколько_денег_я_буду_иметь_с_продажи_одной_фотографии

to david_m
Меня всегда интересовало на основе какой СУБД строятся базы фотоагенств.
В Лори какая СУБД используется? Сильно подозреваю, что Oracle.

Насчёт «баз фотоагентств» вообще — не знаю, а у нас PostgreSQL. Но на самом деле, это не принципиально — я не вижу там ничего такого, что нельзя было бы реализовать хоть на Оракле, хоть на MySQL.

Те цены что я указал, я взял из своей статистики, может для меня какие особые цены, не знаю.
я конкретно про - Некоммерческая для полиграфии, А4 = 1 200 / 600 р.
но я не против вместо 300 р получать 600.
Зря наверное сказал, сейчас придет бухгалтерия и все пересчитает (((

% автору зависит от размера фотографии - веб 20%, А6 - 30%, А5 - 40%, а4 и выше - половина.

А вот цена бывает какая угодно (но не ниже, чем в табличке).

У нас бывали партнерские продажи с выплатой автору 6000 за фото.
И ничего.... Нам не жалко