37-ичная система исчисления

[Zander]

Неправильно ты понял
Ссылка - это набор символов, а не цифр, поэтому перевести её в какую либо систему счисления не получится.
Поэтому ссылка заносится в БД и получает определённый id, допустим 7854223854.
Вот этот id и переводится. В итоге вместо _http://www.supersite.com/user/foto/128.jpg получим _http://www.redirect.com/1D425F1EE (в шестнадцатиричной системе счисления, в 36-ричной будет ещё короче).

Не люблю цитировать сам себя... Но если некоторые не в состоянии прочитать, то, что написано по-русски, придется...

На входе сервиса - длинная ссылка (строка), состоящая из произвольных символов, а не только из десятичных цифр.

Почему ссылке так необходимо присваивать десятичный ID? Почему не адрес в Москве? Типа 3-я улица Строителей?
Кто мешает сразу присвоить 36-ричный Id? Например такой "00K", а следующему "00L", ну и так далее... При этом не надо ничего никуда переводить. Таблица из двух столбцов. Ссылка входная, ссылка выходная. Все!
Нет, если, конечно, очень надо сделать все, чтобы сервис был очень тормозным, то можно еще придумать пару-тройку бесполезных промежуточных преобразований...

 

[KillDead]

Ага, и хратить будите где? Если сервис будет популярен, то сервак нужен неслабый.
Правельнее будет написать какой-нить алгоритм упаковки.

 

[B1rdEX]

А зачем придумывать пак? CRC32 справится.

Выходное значение после црц32 - 8-ми символьное слово в HEX

Процент коллизий для миллиона входных данных:
1 000 000 / (2^32) = 0.000232830644

На мой взгляд, это оптимальнее 37-ричной СС.

 

[KillDead]

А зачем придумывать пак? CRC32 справится.

Выходное значение после црц32 - 8-ми символьное слово в HEX

Процент коллизий для миллиона входных данных:
1 000 000 / (2^32) = 0.000232830644

На мой взгляд, это оптимальнее 37-ричной СС.

Опять. Если знаем для чего нужен CRC32 смотрим пост выше.
Люди начали заговариваться. Хотя точное ТЗ не известно. Кажется тема уже поднималась
Для просмотра ссылки Войди или Зарегистрируйся.
-------------------
Подведу итог - Есть 2 способа:
1- Делаем базу, куда будем заносить все ссылки. Никаких хэшей! Просто возвращаем id добавленной записи. Затем его можно преобразовать по своей системе счисления. Это ещё больше уменьшит размер ссылки.
+ малый размер ссылки
- необходимо держать огромную базу. Со всеми вытекающими
2- Используем алгоритм сжатия ссылки.
+ требования к серверу минимальны, не надо ничего ни хранить ни искать.
- трудно реализовать (хотя для кого как), размер укороченных данных быдет невпример больше.

 

[Zander]

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

 

[murich]

Ну что вы в самом деле о тз спорите- tinyurl.com видали?
Сжимать ссылку по алгоритму, получая 8 символьный хеш - не то, задача получить короткий идентификатор.
ну а насчет того где все это хранить - можно в принципе текстовые файлы посоздавать имя файла = идентификатору, контент = урлу.
Насколько я знаю, такой расклад должен работать с одинаковой скоростью в независимости от кол-ва ссылок в "базе". Так?

 

[PHP_Master]

Ага, и хратить будите где? Если сервис будет популярен, то сервак нужен неслабый.
Правельнее будет написать какой-нить алгоритм упаковки.

1. Даже если сервис будет мегапопулярным, нагрузка от примитивных одноранговых sql-запросов не будет сумасшедшей. Для этого вполне можно использовать и SQLite.
2. Тебе знакомы простые, разумные и, самое главное обратимые, алгоритмы паковки коротких строк?

 

[Lonely Wolf]

О боже.... читал со слезами на глазах... зачем вы вечно усложняете себе жизнь? Типа кто круче и сложнее придумает колесо?
Юзай БД делаешь 1 таблицу ставишь правильно индексацию id, url и всё, на id автоинкримент, на url ставишь уникальный - всё!
1 запрос по номеру и твоя ссылка на выходе на редиректе.
Кто там говорил про нагрузку? Знаете что такое нагрузка, это когда 50 запросов на странице с БД в несколько ГБ вот это нагрузка.
Лимит одной таблицы 4гб в среднем, после она начинает подвисать при выборке.
Делаем просто, у нас всего 2 поле, одно инт, другое варчар, я сомневаюсь что даже пи 500т. записей он привысит лимит в 4гб или хотя бы приблизиться к нему, учитывая что урл уникальный, а ид автоинкримент 1 запрос на выборку по where займёт считаные доли секунд и никакой нагрузки.

Так не изобретайте новое колесо, лучше уже не сделать чем то, что есть

 

[murich]

Оно так сейчас и есть.

 

[PHP_Master]

Lonely Wolf, так я об этом и писал.
Затея с переводом - это для укорачивания id ссылки.
Бредни про нагрузку - это по незнанию и/или неопытности.