Каковы шансы для пожарного магазина сгенерировать два одинаковых случайных ключа?

Question

Каковы шансы для пожарного магазина сгенерировать два одинаковых случайных ключа?

Здесь вы должны абсолютно использовать подготовленный оператор, который бы справлялся с проблемой правильного экранирования одной кавычки при вставке. Что-то вроде этого:

String sql = "INSERT INTO Projektname(projektname) VALUES(?)";

try (Connection conn = this.connect();
    PreparedStatement pstmt = conn.prepareStatement(sql)) {
        pstmt.setString(1, txtFd_name.getText());
        pstmt.executeUpdate();
} catch (SQLException e) {
    System.out.println(e.getMessage());
}

Если вы должны продолжить свой текущий подход, вы можете попробовать вручную удвоить все одинарные кавычки. Поэтому может сделать вашу текущую работу вставки:

String name = txtFd_name.getText().replaceAll("'", "''");
String sql = "INSERT INTO Projektname(projektname) VALUES('" + name + "');");
Main.execute(sql);

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

0

firebase google-cloud-firestore

задан Jama Mohamed 19 January 2019 в 14:48

2 ответа

Другие вопросы по тегам:

firebase google-cloud-firestore

Похожие вопросы:

score 0 · Answer 1

Хотя ответ Гастона Сайлена на 100% верен в отношении нажатой клавиши из базы данных Firebase в реальном времени, я постараюсь добавить еще несколько деталей.

При использовании метода DatabaseReference push () он генерирует ключ, который имеет компонент времени, поэтому в принципе два события могут происходить теоретически в течение одной миллисекунды, но существует астрономически малая вероятность того, что два пользователя могут генерировать ключ в тот же момент и с той же случайностью. Также обратите внимание, что эти ключи генерируются полностью на клиенте без консультации с сервером Firebase. Если вам интересно, вот алгоритм , который генерирует эти ключи . В конце я могу сказать вам, что я не слышал о человеке, который до сих пор сообщал о проблеме с ключевыми столкновениями.

Таким образом, в отличие от ключей базы данных Fireabase в реальном времени, идентификаторы Cloud Firestore фактически являются случайными. Там нет времени компонент включен. Этот встроенный генератор уникальных идентификаторов, который используется в Firestore при вызове методов CollectionReference add () или метода CollectionReference document () без передачи каких-либо параметров, генерирует случайные и крайне непредсказуемые идентификаторы , что предотвращает попадание в определенные горячие точки в серверной инфраструктуре. Это также причина, по которой нет порядка, если вы проверяете документы в коллекции в консоли Firebase. Столкновения идентификаторов в этом случае невероятно малы, и вы можете / должны предположить, что они будут полностью уникальными. Вот для чего они были созданы. Что касается алгоритма, вы можете проверить ответ Фрэнка ван Пуффелена из этого поста . Так что вам не нужно беспокоиться об этих идентификаторах.

score 0 · Answer 2

Согласно этой ссылке в блоге: 2 ^ 120 способов обеспечения уникальных идентификаторов

Как генерируются push-идентификаторы

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

Что такое Push ID?

Push ID содержит 120 бит информации. Первые 48 битов представляют собой временную метку, которая уменьшает вероятность коллизий и позволяет последовательно создавать идентификаторы push для сортировки в хронологическом порядке. За меткой времени следует 72 бита случайности, что гарантирует, что даже два человека, создающие идентификаторы push-сообщений в одну и ту же миллисекунду, вряд ли будут генерировать идентичные идентификаторы. Одно предостережение от случайности заключается в том, что для сохранения хронологического упорядочения, если клиент создает несколько push-идентификаторов за одну и ту же миллисекунду, мы просто «увеличиваем» случайные биты на единицу.

Чтобы превратить наши 120 битов информации (отметка времени + случайность) в идентификатор, который можно использовать в качестве ключа Firebase, мы в основном base64 кодируем его в символы ASCII, но мы используем модифицированный алфавит base64, который гарантирует, что идентификаторы все равно будут сортироваться правильно при лексикографическом порядке (поскольку ключи Firebase упорядочены лексикографически).