Грабельки MySQLные

[dil]

А вот кто может пояснить, почему вот на такой синтаксис MySQL ругается:

CREATE TABLE `foo` (
  `bar` varchar(32) NOT NULL,
  UNIQUE KEY `bar` (`bar`) USING BTREE
);

а вот такой спокойно принимает:

CREATE TABLE `foo` (
  `bar` varchar(32) NOT NULL,
  UNIQUE KEY `bar` USING BTREE (`bar`)
);

?

Сервер 5.0.51a. Документация говорит нам, что index_type может присутствовать как до списка (index_col_name,…), так и после. Самое смешное, что первый вариант синтаксиса был выдан командой show create table из другого mysql-сервера (5.1.36). Как же так, наши пластинки и к нашему же проигрывателю не подходят?

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме

Comments

[1master.livejournal.com]

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

Со вложенностью как раз проблем нет, если тэги поддерживают иерархичность. Грубо говоря, если "Москва" и "Россия -> Москва" - могу быть разными тэгами.

[dil.livejournal.com]

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

2) а как их вложенные показывать в облаке тэгов? как "Россия->Москва"? А если оно на десятом уровне вложенности?

[1master.livejournal.com]

1) Серии обычно тематические и могут требовать дополнительного оформления. Если у тебя такой потребности нет, то можно и забитью
2) Раскрывать по мере приближения. Посмотри, как это WL Photo Gallery делает, у нее как раз такая конструкция (фолдеры, правда, тоже есть, но лично я ими практически совсем не пользуюсь).

[dil.livejournal.com]

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

кто есть Wl Photo Gallery?

[1master.livejournal.com]

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

http://download.live.com/photogallery

[dil.livejournal.com]

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

[1master.livejournal.com]

Ну это уже тонкости, сколько именно полей пометить как reserved :)

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

[dil.livejournal.com]

интересная идея, я в эту сторону вообще не думал..

[bormotov.livejournal.com]

в том-то и дело, что различия будут нужны на уровне представления.

В одном случае, нужен плоский список (облако?) уникальных имён (теги), в другом нужна иерархия, в которой каждый элемент пути может быть не уникальным.

Мне нравится как иерархичность тегов сделана в LightRoom - теги все самостоятельны, но можно сказать, что при выборе тега "животные", выбирать все фотографии у которых тег "млекопитающие". В дереве тегов это будет выглядеть
"животные" -> "млекопитающие". При этом я могу повесить на фото как "животные", так и "млекопитающие".

[dil.livejournal.com]

фактически тэг "млекопитающие" становится подтэгом от "животные". получаем иерархическую структуру тэгов.

или они неиерархическая? "млекопитающие" могут одновременно быть частью какого-нибудь другого тэга, если они уже являются частью "животных"?

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

[bormotov.livejournal.com]

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

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

Как в детстве было - альбом "детские фотографии", потом "школьные", потом "выпускной", и тд. Конечно никто не мешал смотреть альбомы с середины, но порядок фотографий значение имел. Альбом нужен, для последовательной выборки элементов из списка (итератор)

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

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

Технически я бы тоже делал это всё через теги. Фотки заливать в одно место, во всех других местах делать ссылки. Но "альбом" и "тег" - это разные по способу обработки элементы.
Хранить их в одном списке или в двух - вопрос реализации. Считать ли название альбома в то же время и просто тегом - вопрос реализации.

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

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

[dil.livejournal.com]

без нарушения общности можно добавить к тэгам упорядоченность. тогда они совсем сольются с альбомами

[lifewalker.livejournal.com]

Ещё по-хорошему в альбом ты можешь вставлять одно и то же фото больше одного раза.

[dil.livejournal.com]

в один альбом одно и то же фото больше одного раза? а зачем?

[lifewalker.livejournal.com]

Если альбом = слайдшоу, то, например, хочу я, чтобы оно начиналось и заканчивалось одним и тем же кадром. Художественный замысел такой. Имею право.

[dil.livejournal.com]

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

[dil.livejournal.com]

пгоди, а оно что, standalone program, а не сайт?
под wine же наверняка не заведется..

[1master.livejournal.com]

Standalone. С дыркой под плагины, ежель надо к какому сервису прикрутить. Про wine понятия не имею.

[dil.livejournal.com]

так это ж мне надо будет windows запускать..

[bormotov.livejournal.com]

+1

[fantaseour.livejournal.com]

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

Альбомы близки к физическому хранилищу по своей логике, а тег это ссылка.

Однако я не делал себе больших альбомов с фото, и рассуждаю совершенно абстрактно.

Для маленьких коллекций можно альбомы совершенно упразднить -- они только мешаются.

[dil.livejournal.com]

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

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

[1master.livejournal.com]

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

[dil.livejournal.com]

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

[dil.livejournal.com]

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

[1master.livejournal.com]

Ага, ага. Первый же тэг на котором ждет облом будет называться "я". Следующие "дом", "работа", "офис". Ну и далее со всеми остановками.

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

[1master.livejournal.com]

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

[dil.livejournal.com]

да ну, фигня какая, вот на яндекс-фотках замечательно работает: я (http://fotki.yandex.ru/tag/%D1%8F/) , и никто не жалуется :)

понятно, кроме общего на всех пользователей облака есть ещё и персональное.

[1master.livejournal.com]

Скорее всего потому, что никто и не пользуется :)

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

[lifewalker.livejournal.com]

Альбом - это произвольным образом упорядоченная группа фотографий. List vs Set короче.

[dil.livejournal.com]

ну пусть они и внутри тэга будут упорядоченные, это ничего принципиально не меняет

[yuricle.livejournal.com]

« АльбомПоУмолчанию, в который фотография автоматически попадает, если ее удалить из всех остальных альбомов» называется Trash (или Recycle Bin).

[dil.livejournal.com]

ну тоже вариант :)

[dimas.livejournal.com]

Если сделать возможность показать иерархию тегов, то, может быть, можно от альбомов и избавиться ...

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

И во линковка фотографий в другой альбом - да, в случае альбомов этого порой сильно не хватает ...

[dil.livejournal.com]

ну так, я, собственно, и предлагаю их слить. иерархия остаётся.

тэги к альбому - это интересная мысль. но если надо просто находить по тэгу все фотографии из альбома (а не сам альбом), это успешно заменяется операцией "проставить тэг для всех фотографий в альбоме". хотя есть существенная разница: если после этого в альбом будут добавляться новые фотографии, у них этот тэг автоматически не добавится.

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

[pash7ka.livejournal.com]

На мой взгляд - тэги и альбомы это разные сущности, принципиально разные способы структурировать данные. Альбомы реализуют древовидную модель, тэги - облачную.
Возьмем, для примера, человека который много и часто фотографирует. Он может каждый день скидывать фотки в альбом по дате: дерево вроде ~/foto/2009/11/24 и при этом он захочет помечать эти фотографии тэгами: "я", "Катя", "закат" и т.п.
Получаются две независимые структуры. Разумеется, можно отказаться от одной из них и эмулировать ту же функциональность средствами другой: сделать древовидные тэги (отказавшись от настоящего дерева альбомов) или сделать симлинки позволив одной фотке быть в разных альбомах эмулируя тем самым часть функциональности тэгов.
Вопрос - надо ли?

[dil.livejournal.com]

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

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

[pash7ka.livejournal.com]

На мой взгляд оба способа должны существовать параллельно. Просто иногда удобнее искать фото в дереве (если знаешь мероприятие где она сделана или дату), иногда по тэгу - если знаешь что там сфоткано, но не знаешь где/когда.

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

Я смотрю на реализацию дерева тэгов в GMarks (https://addons.mozilla.org/ru/firefox/addon/2888), и кажется мне, что это вовсе не простая задача - реализовать такое дерево, чтоб оно работало стабильно.

[dil.livejournal.com]

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

техническую реализацию я вообще не трогаю, речь только о логической модели.
про минусы не понял.
1) никаких обычных тэгов с каким-то особым синтаксисом нет, есть только унифицированные тэго-альбомы.
2) это отдельный вопрос, не связанный с моделью. точнее, так: в традиционной модели это вопрос возможности присваивания тэгов альбомам а не отдельным фотографиям (а это вообще где-то реализовано?). в предлагаемой модели - вопрос недревовидной структуры тэгоальбомов, чтобы один альбом мог входить сразу в несколько других.
3) вопрос реализации. если тэг/альбом идентифицируется не по имени, а по внутреннему [числовому] ID, то имя можно спокойно менять, не трогая привязку фотографий

[pash7ka.livejournal.com]

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

Возвращаясь чисто к логическому представлению: их нужно два. Пример из другой области: почтовый адрес.
В виде дерева это Страна/Город/Улица/Дом/Квартира. В таком дереве любой адрес можно быстро и удобно найти. Можно представить его как тэг Страна-Город-Улица-Дом-Квартира, но очевидно искать сразу станет неудобно, придется соритровать по имени и фактически придем к той же древовидной структуре.
С другой стороны, облако тэгов очевидно полезно, отказываться и от него нельзя.

никаких обычных тэгов с каким-то особым синтаксисом нет, есть только унифицированные тэго-альбомы
А на конкретном примере?
Вот например, я хочу иметь древовидную структуру альбомов:
2008
-- Франция
-- Германия
2009
-- Германия
-- Египет
Плюс к этому я хочу некоторым фоткам дать теги "я", "мама", "папа", "Катя", "цветочки", остальным фоткам (их большинство), мне будет лень присваивать тэги.

Какое облако тэгов у меня в итоге получится?

[ifapru.livejournal.com]

ИМХО, это не идея логического слияния альбомов тэгов в тегоальбомы, а декларация о надуманности понятия "альбом" как такового. Ну вроде да, альбом - это из офлайна, а в виртуале - теги, так оно и удобнее, и реализует потенциал ИКТ, которого нет в офлайне, поэтому там альбомы. Но это в теории, а на практике это будет работать только в двух случаях:
1. Фотографий сравнительно немного;
либо
2. Юзер не ленится к каждой из них писать много тегов.

Потому как в общем случае юзер нифига не найдет уже в свалке из 100 фотографий, т.к. у каждой будет что-то вроде "котятки, ути-пути, 2009". Ну, тег года еще может разниться ;)))