Прим Палвер:
Ключ - это поле с уникальными значениями? Соответственно ID cкорее всего и будет ключом..

Поле `address` тоже уникальное.
Я спрашиваю о том, как сделать оптимальнее.
ЧПУ - уже решённый вопрос.
Теперь стоит вопрос о скорости.
Чувствую, что первичный поиск `id` по полю `address` будет горлышком лейки.
Поэтому и спрашиваю о том, как сделать этот поиск по базе быстрее и каким ключом делать поле `address`.
Думаю, что поиск по числу, тем более первичному ключу, будет идти намного быстрее, чем по слову.
Надеюсь, что выразил вопрос уже достаточно понятно?

Прим Палвер:
ЧПУ, это "чрезмерное потребление улиток"? что есть ЧПУ?
Поиск по первичному ключу, как и по любому индексу будет намного быстрее, т.к. это индексируемое пространство.
Если у Вас адрес действительно уникальный, так зачем еще делать и суррогатный ключ???
Что быстрее, искать по varchar или int не корректен, ибо т.к. в обоих случаях использует кэш индекса, и по сути они работают одинаково.
Если же у Вас "адрес" это что-то длинное (предисловие к басни например) то оно по определению не может быть уникальным, хотя и вполне законно наложить это свойство на такое поле.
С другой стороны, если у вас есть ссылочные зависимости на эту таблицу, то вероятно тащить за собой адрес не стоит, и надо использовать id.
Вопрос не совсем понятен в силу элементарности понятий - id используется для того, что бы:
- или создать уникальный ключ в условиях отсутствия детерминанты (потенциальных PK (Primary key))
- или сократить ссылочную зависимость (вместо 2-3-6 полей возможного PK тащится только один ID который становится первичным ключом)
В вашем случае скорей всего второй вариант. Следовательно, тут и рассуждать не о чем. ID это первичный ключ, и если БД позволяет, то автоинкрементный. А на «адрес» можно наложить ограничение уникальности если есть желание. Ну и его проиндексировать.

Как-бы модератор...

ЧПУ

Человеку Понятный Урл.
Вы с таким не сталкивались?
Я что-то изобрёл?

Пока осмысленных ответов не было.
Всё остальное я не спрашивал.

Вопрос: как сделать быстрее при поставленных условиях.
Повторюсь: вначале ищем id по известному (тоже уникальному) address.
Ничего больше писать не нужно - я этого не спрашиваю.

Администрация:
Скажите, уважаемые админы, незнание модератором вопроса - это повод для приколов?
Такие ответы вы собирались где-то там публиковать?

Прим Палвер:
В мире есть множество сокращений, и не стоит наедятся что все знают то, о чем Вы думаете, я не "прикололся", а реально предположил, ибо под URL >>ЧПУ чаще понимают нечто иное. Данная рассылка о SQL а не WEB технологиях и потому из контекста не понятно что имеется ввиду.

Я уже дал Вам ответ в минифоруме. Никто никогда не ищет id, ибо идентификатор сам по себе не несет информации, если это не параметризованный запрос с явным указанием ID как обращение связанной таблицы.

В Вашем случае - ID - есть PK, а `address` - просто индексированное поле, возможно уникальное. Будет быстро.

Модераторы:
Добрый вечер! Прошу внести изменения в ответ, в связи с орфографической ошибкой. Вместо "..крититична?" требуется "..критична?"

leonid59:
Внимательней относитесь к своим ответам.
Удачи!

Надо посчитать, а какое количество записей в вашей базе: сто тысяч, миллион? Может, скорость обращения к записи и не столь критична?

Да проще план запроса посмотреть и по стоимости сделать вывод. Если full-scan то думать о разумной индексации. Хотя, в "двух соснах" сложно искать еще что-то (если брать только ID & ADDRESS) а вот если есть и другие поля, стоит в случае большой стоимости (не оптимального плана) подумать об изминении запроса и переиндексации.

Да, предлагаю открыть подкаталог
"Поисковая оптимизация"

Уже кучу вопросов задал в никуда, потому что в "поиске", оказывается, ищут информацию обо всём.
В базах данных ... вот такие оказии случаются.
В php тоже не все в курсе, что есть ЧПУ или modrewrite или .htaccess...

Я прихожу сюда в надежде, что отвечающий окажется умнее меня в данном вопросе.
Тем более модератор.

...улитки...

Прим Палвер:
Уникальный индекс, если вы хотите, чтобы сервер отслеживал уникальность записи по полю address.
CREATE UNIQUE INDEX address_idx ON TableName (address);

да уникальность я сам в php прослеживаю
а как быстрее поиск этой строки сделать?
Какой индекс ставить?

Прим Палвер:

Какой индекс ставить?

Уникальный индекс. На протяжение всего минифорума Вам об этом говорят. Впрочем, уникальность тут как дополнительный атрибут. Просто проиндексируйте это поле - не первичный ключ

да уникальность я сам в php прослеживаю

с точки зрения баз данных - безсмысленный труд, это может делать СУБД.

В php тоже не все в курсе, что есть ЧПУ или modrewrite или .htaccess...

Это разные вещи, ЧПУ, или "адаптированный URL", модуль динамического форматирования строки, и файл настроек WEB сервера Apache.

В сайте вся работа происходит по первичному ключу, соответствующему id. Но изначально сам id ищется по значению адреса в базе. Вопрос: каким сделать этот ключ, соответствующий адресу?

Ответ:
ID - делайте первичным ключем
ADDRESS - индексируемым полем, если требуется вводить только уникальные адреса, то дополнительно наложите ограничение уникальности.

ALTER TABLE `MYTABLE` ADD `PK_MYTABLE` PRIMARY KEY (ID);
ALTER TABLE `MYTABLE` ADD UNIQUE `UIQ_ADDRESS` (ADDRESS); -- ЕСЛИ НУЖНА УНИКАЛЬНОСТЬ
ALTER TABLE `MYTABLE` ADD INDEX `IDX_ADDRESS` (ADDRESS); -- ЕСЛИ УНИКАЛЬНОСТЬ НЕ НУЖНА

( для справки, операторы ddl всегда фиксируются СУБД, потому, при приобразовании в уникальное поле, возможна потеря данных без возможности их отката (ROLLBACK тут не работает))

Victor Pyrlik:
Доброе утро, уважаемый Victor Pyrlik! Спасибо за сообщение, но это не мои цитаты :)

Прим Палвер:
Доброе утро, Прим Палвер! Скорее всего, надо вернуться к первому этапу: постановке задачи. После этого проектируем и тестируем серверную часть, после этого - клиентскую. Опишите задачу более подробно - из этого можно построить таблицы и бизнес-логику, включая ограничения. Вполне возможно, и другие события вы обрабатываете неоптимально (на клиенте). Если у вас уже есть полный скрипт - его тоже лучше посмотреть

leonid59:
Ошибся :)
В остальном, по последнему посту +1