November 2019

S M T W T F S
      12
34 5 678 9
10111213141516
17181920212223
24252627282930

Style Credit

Expand Cut Tags

No cut tags
Monday, September 28th, 2009 02:16 pm

А вот кто может пояснить, почему вот на такой синтаксис 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 в любой форме и любом объёме

Tuesday, November 24th, 2009 04:13 pm (UTC)
дата это вообще отдельный вопрос, если только она не упомянута в названии альбома.

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

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

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

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