Версии тайлов

[vasketsov]

Вопрос касается проектирования структуры БД.
Хватит 2 байта под версию тайла?
Это равносильно существованию 65535 различных версий для одной карты (плюс 0 для "без версии").

[zed]

Смотря для какой карты. В общем случае, версия - строковый параметр. К примеру, у Яндекса это что-то вроде "1.32.0" и в 2 байта это втиснуть будет проблематично.

[vasketsov]

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

Впрочем продолжим. Имеет смысл делать поле crc32 int null для тайлов, чтобы не сохранять более новые версии, если тайл такой же (соответственно идентичность определять по crc32)? И если да - как обеспечить сохранность тайла, если из старой версии его захочется удалить?
Или достаточно уметь просто безо всяких сравнений тайлов возвращать предыдущую версию, если запрошенной нет?

[Parasite]

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

Ну вообще-то PRIMARY KEY нормально строиться на текстовые поля, если поле ограничено в длине (как минимум в мускуле - строится). То есть, "TileVer text|char primary key" - будет еррор, а "TileVer text|char(10) primary key" - таки сработает.
Понятно что не очень изящно, но работать - будет, и без доп.костылей...

[vasketsov]

Ну вообще-то PRIMARY KEY нормально строиться на текстовые поля, если поле ограничено в длине (как минимум в мускуле - строится)

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

и без доп.костылей...

С каких это пор суррогатный ключ и ссылка на него из таблиц с тайлами - костыль?

[Parasite]

Ну вообще-то PRIMARY KEY нормально строиться на текстовые поля, если поле ограничено в длине (как минимум в мускуле - строится)

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

Угу. Особенно при текстовом поле и полнотекстовом индексе (кой часто и получается больше самого поля раза эдак в два с половиной). Проходили-сс... Но для нужд обычного среднестатистического юзверя = сработает, у него как правило далеко не 100500 сотен тайлов, да и сервера-то как такового нет...А нуждам продвинутого - все равно никогда на 100% не угодишь. Имхо.
Впрочем - согласен, решение корявое.
PS: Но работоспособное до поры до времени.

и без доп.костылей...

С каких это пор суррогатный ключ и ссылка на него из таблиц с тайлами - костыль?

"костыль " = "религия не позволяет. Поэтому и приходится городить ссылку на версии в таблице с тайлами"©