Грабельки 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

[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
-- Германия
-- Египет
Плюс к этому я хочу некоторым фоткам дать теги "я", "мама", "папа", "Катя", "цветочки", остальным фоткам (их большинство), мне будет лень присваивать тэги.

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