В моем образовании мне говорили, что ошибочно предлагать пользователю фактические первичные ключи (не только ключи БД, но и все первичные средства доступа).
Я всегда думал, что это проблема безопасности (потому что злоумышленник может попытаться прочитать что-то не свое).
Теперь я должен проверить, разрешен ли пользователю доступ в любом случае, так есть ли другая причина?
Кроме того, поскольку мои пользователи в любом случае должны иметь доступ к данным, мне потребуется открытый ключ для внешнего мира где-то посередине. Теперь этот открытый ключ имеет те же проблемы, что и первичный ключ, не так ли?
Был запрос о том, зачем это делать, так что вот один. Имейте в виду, что речь идет о самом принципе, а не только о его применении в этом примере. Ответы на другие ситуации приветствуются.
Приложение (Web, Mobile), которое обрабатывает действия, имеет несколько пользовательских интерфейсов и, по крайней мере, один автоматизированный API-интерфейс для межсистемного взаимодействия (например, бухгалтерия хочет знать, сколько взимать с клиента, исходя из того, что было сделано). Приложение имеет несколько клиентов, поэтому разделение их данных (логически данные хранятся в одной и той же БД) является обязательным требованием системы. Каждый запрос будет проверен на достоверность независимо от того, что.
Активность очень тонкая, поэтому она находится вместе в каком-либо объекте контейнера, давайте назовем его «Задача».
Три варианта использования:
- Пользователь А хочет отправить Пользователя Б какой-то Задаче, поэтому он отправляет ему ссылку (HTTP), чтобы выполнить некоторую Активность там.
- Пользователь B должен выйти из здания, чтобы открыть задание на своем мобильном устройстве.
- Бухгалтерия хочет взимать с клиента плату за задание, но использует стороннюю систему учета, которая автоматически загружает задание / действие с помощью некоторого кода, который ссылается на REST-API приложения
Каждый из сценариев использования требует (или облегчает, если), чтобы агент имел какой-либо адресуемый идентификатор для Задачи и Действия.
ON UPDATE CASCADEбыл создан для этого (специфичен для mysql?), хотя, если проблема заключается в безопасности, тогда проверка доступа должна выполняться на бэкэнде и в любом случае не доверять пользователюОтветы:
Именно так. Возьмем HTTP без сохранения состояния, который иначе не знал бы, какой ресурс он должен запрашивать: он отображает идентификатор вашего вопроса
218306в URL. Возможно, вам действительно интересно, может ли открытый идентификатор быть предсказуемым ?Единственные места, где я слышал отрицательный ответ, использовали обоснование: «Но они могут изменить идентификатор в URL!» , Таким образом, они использовали GUID вместо реализации правильной авторизации.
Я могу представить одну ситуацию, когда вы не хотите, чтобы ваши идентификаторы были предсказуемыми: сбор ресурсов. Если у вас есть сайт, на котором публично размещаются определенные ресурсы, которые могут быть интересны другим, и вы размещаете их как,
/images/n.jpgили/videos/n.mp4гдеnчисло увеличивается, любой, кто просматривает трафик на ваш сайт и с него, может собрать все ваши ресурсы.Итак, чтобы прямо ответить на ваш вопрос: нет, неплохо бы напрямую «выставлять» идентификаторы, которые имеют значение только для вашей программы, обычно это даже требуется для успешной работы вашей программы.
источник
Вы не должны выставлять это, потому что люди, которые видят это, начнут использовать это как их «номер счета», который это НЕ. Например, для моего банковского счета я знаю, какой номер моего счета. Я запомнил это, я использую это по телефону со службой поддержки клиентов, я использую это при заполнении форм для других банков, чтобы сделать переводы, для юридических документов, для моей службы автоматической оплаты и т. Д., И т. Д. Я не хочу это изменить. Первичный ключ (для моей учетной записи), с другой стороны, я не знаю или никогда не вижу.
Система, в которой он хранится, с годами изменяется от одной системы к другой посредством банковских слияний, обновлений и замен системы и т. Д.
И т . Д. Первичные ключи могут изменяться в результате некоторых из этих преобразований, поэтому, если они никогда не были раскрыты, записаны или запомнены любым обычным пользователем, который
Ключи, не имеющие делового значения, часто называют суррогатными ключами и часто (но не всегда) используются в качестве первичных ключей.
Кстати, это даже происходит внутри, когда люди создают интерфейсы и программы, которые неправильно используют и выставляют первичные ключи и делают их частью таких систем вместо того, чтобы просто делать одно - однозначно идентифицировать внутреннюю запись базы данных. Я на самом деле узнал об этом через 6 лет поддержки системы хранения данных в больнице.
источник
Потому что первичные ключи - это детали реализации.
Если вы переносите базы данных, ваши первичные ключи могут измениться из-за порядка вставки, удаления старых записей ... по нескольким причинам. Если вы переносите платформы баз данных, у вас может вообще не быть фактического первичного ключа. Представление PK над уровнем доступа к данным является утечкой абстракции со всеми вытекающими проблемами связывания.
источник
Это комбинированный ответ других (иначе, что я узнал). Если вы чувствуете, что хотите проголосовать против этого, вы должны, по крайней мере, проголосовать за других, так как они сделали настоящую работу. Если вас больше интересует, прочитайте другие ответы.
Вы не должны выставлять первичный ключ базы данных, а вместо этого использовать суррогатный ключ
Примечание. Созданный вами ключ должен быть (как бы) понятен человеку ( ответ Sqlvogels ).
Если вашей системе не нужны цифры от 1 до 4., то нет причин не использовать базы данных PK в качестве вашего открытого идентификатора (несколько ответов). Также безопасность не является проблемой здесь (несколько ответов).
источник
Одна причина, которую я обнаружил, это то, что конечный пользователь просил, чтобы его идентификатор что-то значил (например, наличие префикса или указатель года, в который он был введен). Сменить ПК сложно, но суррогат гораздо проще.
Ваш первичный ключ, вероятно, будет тем, что вы хотите, чтобы ваша база данных индексировалась по соображениям производительности, и вы можете со временем по техническим причинам изменить его, например, с номера на guid ... вы просто не знаете, по каким причинам новые технологии или знания может вести вас вниз. Ваш ПК - это ваш технический элемент данных, открытый ключ предназначен для конечных пользователей.
источник
InvoiceNumber, которая имеет значение и может изменяться клиентом, но я также раскрываю информациюInvoiceID, которую мой код использует для уникальной идентификации счета. Вам не нужно (и чаще всего не хотите ), чтобы ключ пользователя был ключом хранилища. Этот вопрос о последнем.InvoiceNumber(для разных арендаторов), но иметь разные первичные ключи - точку (вид ) также упоминается в ответе.Для большинства приложений очень важно, чтобы вы действительно открывали ключи для пользователей. Чтобы эффективно использовать информационную систему, пользователям этой системы обычно требуется способ идентифицировать информацию в ней и связать эту информацию с чем-то в мире вне базы данных. В терминах реляционной базы данных эти идентификаторы являются ключами.
Один из широко используемых шаблонов проектирования - это создание дополнительного, чисто «технического» ключа для таблиц базы данных в качестве средства абстракции. Например, чтобы обеспечить стабильный (относительно неизменный) ключ, в котором некоторые альтернативные ключи могут быть изменены. Такие технические ключи обычно не предоставляются конечным пользователям, потому что это подрывает предполагаемую абстракцию от требований пользователя. Это не имеет ничего общего с безопасностью.
Проблема / недоразумение, скрытое в вашем вопросе, связано с неправильным использованием термина первичный ключ. Первичный ключ - это только один из нескольких ключей-кандидатов (несколько возможных идентификаторов в таблице базы данных). Первичный ключ не обязательно требует какого-либо принципиально отличного свойства от любого другого ключа, поэтому утверждения и принципы разработки, которые применяются конкретно к первичным ключам, а не к другим ключам, всегда подозрительны и часто ошибочны.
Учитывая, что вам обычно нужно предоставлять ключ вашему пользователю, каким должен быть этот ключ? Постарайтесь сделать ваши ключи привычными, простыми и стабильными. Знакомство и простота делают ключи легкими для чтения и запоминания и помогут избежать ошибок при вводе данных. Стабильность означает, что ключ меняется нечасто, что также помогает избежать возможности ошибочной идентификации.
источник
Это из комментария на ответ Greystone28 от CodeCaster. Это пример того, что вы говорите:
Какую цель в вашем приложении выполняет воспроизведение InvoiceID?
Под разоблачением я предполагаю, что вы имеете в виду, что пользователь может видеть это. Выставляйте его только в том случае, если он нужен пользователю для использования вашего приложения. Это может быть использовано технической поддержкой или некоторыми административными сотрудниками. Я работал с несколькими приложениями, которые делают это. Это облегчает оказание поддержки, когда я знаю конкретную запись, о которой идет речь.
источник
Это совершенно нормально для сущностей, имеющих уникальный идентификатор, который выставляется внешнему миру. Для некоторых объектов может быть возможно найти идентификатор, который на самом деле имеет значение (например, номер счета), но для других такой идентификатор не существует и, следовательно, его необходимо сгенерировать.
Для согласованности и читабельности я считаю хорошей практикой для всех сущностей в системе использовать один и тот же тип и имя для своего идентификатора. Обычно этот идентификатор будет выставлен (
<type> getId()) в некотором абстрактном базовом классе.По той же причине каждая служба в системе (например, служба выставления счетов) должна предоставлять идентичные методы для доступа к объектам по их идентификатору. Обычно этот метод (
findById(<type> id)) наследуется от универсального интерфейса службы или базового класса.Этот идентификатор не обязательно должен быть первичным ключом объекта, но он может быть одним. Единственное, что нужно гарантировать, - это то, что стратегия генерации ключей создает разумно уникальные идентификаторы (необязательно универсально уникальные, но, по крайней мере, внутри системы).
Если впоследствии система будет перенесена (если в моем случае это будет большой объем) в другую базу данных, то не составит труда использовать другую стратегию (не основанную на первичных ключах) для создания идентификаторов, если стратегия совместима с исходной.
источник
Здесь есть первичный ключ, как дескриптор кортежа (запись, строка), к которому вы пытаетесь обратиться как разработчик. Он также используется в ссылочной целостности (ограничения внешнего ключа), и, возможно, он также имеет один или несколько вариантов использования.
По сути, нет ничего плохого в том, чтобы показывать его пользователям или даже хакерам. Потому что я не знаю атаки, которая использует первичный ключ, например.
Но в области безопасности у нас есть много принципов (которые мы принимаем и не одобряем), и нам нужно их придерживаться:
И некоторые другие принципы. По сути, они говорят, что:
Если вам не нужно раскрывать свои данные, зачем вам вообще?
источник