Да, бизнесу нужны сущности. И мы можем идентифицировать сущность по атрибутам, только если мы специально вводили для нее ключ в качестве атрибута — тот же номер счета. С этой точки зрения нет разницы, использовать для идентификации этот уникальный атрибут, или внутренний дополнительный.
Кроме адресации, из плюсов мне пришли в голову примерно такие:
— Без проблем можно перенести данные между таблицами при рефакторинге
— Отображает последовательность создания объектов
— Меньше ресурсов требуется на создание ID для новой записи (по сравнению с guid)
Как нам теперь понять, на каком шарде лежит объект? По диапазону? Дополнительная сущность.
Насколько я знаю, некоторые варианты реализации шардинга предполагают использование диапазонов, есть варианты с централизованным генератором ключей. Так что тут различий почти нет.
Какого типа объект? По диапазону? Еще одна сущность.
Ну таблицы-то никуда не деваются. Просто немного меняется способ генерации ключа.
А если у вас в системе есть короткоживущие объекты — они все равно будут поедать емкость из общего множества идентификаторов?
Да. Если на них бывают внешние ключи в других таблицах, хоть и ненадолго, то в этот момент они являются частью системы. А если не бывают, и если мы не хотим тратить на них идентификаторы, можно завести для них отдельную последовательность.
Множество значений идентификаторов это небольшая проблема. Кроме того, если использовать GUID, то про них тоже можно сказать, что значения поедаются.
А если у вас есть объекты с естественными идентификаторами — для них все равно заводить искусственный и поддерживать две уникальности?
Да. Это ничем не отличается от составного ключа. Ну и технические причины есть, по числовому идентификатору искать быстрее, чем по 20-символьной строке с номером счета.
А если у вас есть связи, у которых «естественный» ключ — составной, с ними как поступать?
Здесь я пожалуй у вас спрошу, как у более опытного. Можете привести пару примеров? Мне не встречались случаи, где это действительно было нужно.
Да, я знаю. Поэтому у меня и появилась мысль о более абстрактном адресе.
Кроме адресации, из плюсов мне пришли в голову примерно такие:
— Без проблем можно перенести данные между таблицами при рефакторинге
— Отображает последовательность создания объектов
— Меньше ресурсов требуется на создание ID для новой записи (по сравнению с guid)
Насколько я знаю, некоторые варианты реализации шардинга предполагают использование диапазонов, есть варианты с централизованным генератором ключей. Так что тут различий почти нет.
Ну таблицы-то никуда не деваются. Просто немного меняется способ генерации ключа.
Да. Если на них бывают внешние ключи в других таблицах, хоть и ненадолго, то в этот момент они являются частью системы. А если не бывают, и если мы не хотим тратить на них идентификаторы, можно завести для них отдельную последовательность.
Множество значений идентификаторов это небольшая проблема. Кроме того, если использовать GUID, то про них тоже можно сказать, что значения поедаются.
Да. Это ничем не отличается от составного ключа. Ну и технические причины есть, по числовому идентификатору искать быстрее, чем по 20-символьной строке с номером счета.
Здесь я пожалуй у вас спрошу, как у более опытного. Можете привести пару примеров? Мне не встречались случаи, где это действительно было нужно.