Когда целесообразно использовать UUID для веб-проекта? - PullRequest
5 голосов
/ 21 февраля 2012

Я занят проектированием базы данных нового проекта, и я не уверен, использовать ли UUID или обычные уникальные для таблицы идентификаторы автоинкремента.

До сих пор все сайты, которые я создавал, работали на одном сервере, и очень большой трафик никогда не был проблемой. Тем не менее, это веб-приложение будет в конечном итоге работать одновременно на нескольких серверах, обслуживать API и должно обрабатывать тысячи запросов в секунду, и я хочу убедиться, что выбранный мной дизайн не нанесет ущерба ни одной из этих возможностей позже.

Конечно, у меня есть свои подозрения, и они должны быть ясны по тому, как я сформулировал свой вопрос, но я хотел бы услышать от тех, у кого больше опыта, с какими проблемами я могу столкнуться позже, если у меня возникнут или нет UUID, и на чем я действительно должен основывать свое решение.

Итак, , кратко : Какие соображения я должен дать при принятии решения о том, использовать или нет UUID для всех моделей базы данных, чтобы любой один объект мог быть однозначно идентифицирован одной строкой, и когда уместно использовать это как первичный ключ, вместо табличного автоматического увеличения?

Примечание : я видел этот вопрос (Когда вы действительно вынуждены использовать UUID как часть проекта?) и прочитать все ответы, но они в основном отвечают «Как редко UUID сталкиваются» вместо «Когда уместно их использовать».

Ответы [ 2 ]

2 голосов
/ 21 февраля 2012

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

И для решения еще одного конкретного вопроса, который вы подняли, он все ещеВозможно использование автоматически увеличивающихся идентификаторов с несколькими серверами (хотя и не со встроенным MySQL).Вам просто нужно запустить все идентификаторы с разными смещениями и увеличивать соответственно.То есть, если бы у вас было 3 сервера, вы могли бы запустить сервер A на 1, сервер B на 2 и сервер C на 3, а затем увеличивать идентификаторы каждый раз на 10 вместо 1. Таким образом, вы можете гарантировать отсутствие коллизий.

И, наконец, последнее, что я рассматриваю, это то, насколько важна производительность для моего приложения.Целые числа гораздо легче индексируются, чем UUID, основанные на строках, поэтому индексы меньше, их поиск выполняется быстрее и т. Д.

1 голос
/ 22 февраля 2012

UUID или GUID могут быть очень полезны, особенно для Интернета.Если вы используете автоинкрементные значения для хранения UserId, любой может просмотреть источник ваших веб-страниц и увидеть простоту его использования.Затем они могут попробовать любое целочисленное значение, чтобы получить данные, которые они не должны видеть.

GUID не создаются ни в каком последовательном формате, поэтому, если вы создаете их один за другим, последовательность не может быть легко угадана.

Я не думаю, что необходимо использовать GUID для простых данных типа поиска, таких как ColorId 1 = синий, 2 = красный, 3 = зеленый.

GUID также очень полезны для сеансаи государственное управление.

Это мои $ 0,02

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...