За и против использования md5 хеш URI как первичный ключ в базе данных

Используйте отражение.

Вот пример неоптимального решения, в котором используется отражение:

public class Main
{
  public static class BlammyOne
  {
    private String propertyDuece;
    private String propertyTree;
    private String propertyUno;

    public String getPropertyDuece()
    {
      return propertyDuece;
    }

    public String getPropertyTree()
    {
      return propertyTree;
    }

    public String getPropertyUno()
    {
      return propertyUno;
    }

    public void setPropertyDuece(
      final String newValue)
    {
      propertyDuece = newValue;
    }

    public void setPropertyTree(
      final String newValue)
    {
      propertyTree = newValue;
    }

    public void setPropertyUno(
      final String newValue)
    {
      propertyUno = newValue;
    }

    @Override
    public String toString()
    {
      final StringBuilder builder = new StringBuilder();

      builder.append("Uno: ");
      builder.append(propertyUno);
      builder.append(", Duece: ");
      builder.append(propertyDuece);
      builder.append(", Tree: ");
      builder.append(propertyTree);

      return builder.toString();
    }
  }

  public static class BlammyTwo
  {
    private String propertyFive;
    private String propertyFour;
    private String propertyUno;

    public String getPropertyFive()
    {
      return propertyFive;
    }

    public String getPropertyFour()
    {
      return propertyFour;
    }

    public String getPropertyUno()
    {
      return propertyUno;
    }

    public void setPropertyFive(
      final String newValue)
    {
      propertyFive = newValue;
    }

    public void setPropertyFour(
      final String newValue)
    {
      propertyFour = newValue;
    }

    public void setPropertyUno(
      final String newValue)
    {
      propertyUno = newValue;
    }

    @Override
    public String toString()
    {
      final StringBuilder builder = new StringBuilder();

      builder.append("Uno: ");
      builder.append(propertyUno);
      builder.append(", Four: ");
      builder.append(propertyFour);
      builder.append(", Five: ");
      builder.append(propertyFive);

      return builder.toString();
    }
  }

  public static void main(
    final String[] arguments)
  {
    final Map<String, String> valueMap = new HashMap<>();
    final BlammyOne blammyOne = new BlammyOne();
    final BlammyTwo blammyTwo = new BlammyTwo();

    valueMap.put("propertyUno",
      "valueUno");
    valueMap.put("propertyDuece",
      "valueDuece");
    valueMap.put("propertyTree",
      "valueTree");
    valueMap.put("propertyFour",
      "valueFour");
    valueMap.put("propertyFive",
      "valueFive");

    settyBetty(valueMap,
      blammyOne);
    settyBetty(valueMap,
      blammyTwo);

    System.out.println("blammyOne: " + blammyOne);
    System.out.println("blammyTwo: " + blammyTwo);
  }

  private static void settyBetty(
    final Map<String, String> valueMap,
    final Object target)
  {
    final java.lang.reflect.Field[] declaredFieldsArray;

    try
    {
      declaredFieldsArray = target.getClass().getDeclaredFields();

      for (java.lang.reflect.Field currentField : declaredFieldsArray)
      {
        final String fieldValue = currentField.getName();
        final PropertyDescriptor propertyDescriptor;
        final java.lang.reflect.Method writeMethod;

        propertyDescriptor = new PropertyDescriptor(
          currentField.getName(),
          target.getClass());

        writeMethod = propertyDescriptor.getWriteMethod();

        writeMethod.invoke(target,
          fieldValue);
      }
    }
    catch (final SecurityException exception)
    {
      System.out.println("SecurityException: " + exception);
    }
    catch (final IntrospectionException exception)
    {
      System.out.println("IntrospectionException: " + exception);
    }
    catch (IllegalAccessException exception)
    {
      System.out.println("IllegalAccessException: " + exception);
    }
    catch (IllegalArgumentException exception)
    {
      System.out.println("IllegalArgumentException: " + exception);
    }
    catch (InvocationTargetException exception)
    {
      System.out.println("InvocationTargetException: " + exception);
    }
  }
}
24
задан rdmpage 21 October 2008 в 08:33
поделиться

6 ответов

После просмотра stackoverfow немного больше я нашел более ранний вопрос Преимущества и недостатки ключей базы данных GUID / UUID , который покрывает большую часть этой земли.

8
ответ дан 29 November 2019 в 00:22
поделиться

Несколько строк могут создавать один и тот же хэш md5. Первичные ключи должны быть уникальными. Поэтому использование хеша в качестве первичного ключа не очень хорошо. Лучше использовать GUID напрямую.

GUID подходит для использования в URL. Конечно. Вот GUID (на самом деле, UUID), который я только что создал с помощью Java: 1ccb9467-e326-4fed-b9a7-7edcba52be84

URL-адрес может быть:

http://example.com/view?id=1ccb9467-e326-4fed-b9a7-7edcba52be84

Это длинный, но вполне пригодный для использования и достигает того, что вы описываете.

1
ответ дан 29 November 2019 в 00:22
поделиться

Возможно, этот документ - что-то, что Вы хотите считать:

http://www.hpl.hp.com/techreports/2002/HPL-2002-216.pdf

0
ответ дан 29 November 2019 в 00:22
поделиться

Часто множество разных URL-адресов указывают на одну и ту же страницу. http://example.com/ example.com http://www.example.com/ http://example.com/index.html http://example.com/ . https://example.com/ и т. Д.

Это может или не может быть проблемой для вас.

0
ответ дан 29 November 2019 в 00:22
поделиться

Это прекрасно.

Случайное столкновение MD5 невозможно во всех практических сценариях (чтобы получить 50% -ную вероятность столкновения, вам необходимо хешировать 6 миллиардов URL в секунду , каждый во-вторых, на 100 лет).

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

Несмотря на то, что существует известная атака коллизий на MD5, преднамеренные злонамеренные коллизии в настоящее время невозможны для хешированных URL-адресов.

  • Тип коллизии, который вам нужен для намеренного коллизии с хешем другого URL, называется pre-image атака. Нет никаких известных изображений до MD5. По состоянию на 2017 год нет исследований, которые бы даже приблизились к осуществимости, поэтому даже решительный хорошо финансируемый злоумышленник не может вычислить URL-адрес, который бы хэшировал хэш любого существующего URL-адреса в вашей базе данных.

  • Единственная известная атака коллизии на MD5 бесполезна для атаки URL-подобных ключей. Он работает, генерируя пару двоичных объектов, которые сталкиваются только друг с другом . Капли будут относительно длинными, содержат NUL и другие непечатаемые байты, поэтому они вряд ли будут похожи на что-то вроде URL.

11
ответ дан 29 November 2019 в 00:22
поделиться

MD5 считается устаревшим - по крайней мере, для криптографических целей, но я бы предложил использовать md5 только для обратной совместимости с существующими материалами. У вас должна быть веская причина использовать md5, когда у нас есть другие алгоритмы хеширования, которые (по крайней мере, пока) не сломаны.

Я вижу проблемы с этим подходом:

  • Дублирующиеся объекты, потому что идентификатор URL отличается (Как уже упоминалось)
  • Изменение URL-адресов

Последнее может быть важным - это можно сделать так же просто, как удаление и добавление. То есть, если эти идентификаторы никогда не видны / не хранятся вне базы данных. (Как компонент URL.)

Думаю, это не будет проблемой для DOI.


Как это будет работать с настройкой целочисленного идентификатора без автонумерации, но когда автономный агент вставки создает числа ? (Может быть, можно использовать выделенный диапазон чисел?) Может возникнуть проблема с дублированием, если два пользователя независимо друг от друга добавят один и тот же URL?

0
ответ дан 29 November 2019 в 00:22
поделиться
Другие вопросы по тегам:

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