Что лучше, использовать центральное хранилище идентификаторов или назначать идентификаторы на основе таблиц

Question

Во многих ERP-системах (локально) я видел, что базы данных (обычно MYSQL) используют центральное хранилище ключей (идентификатор ресурса). Почему это?

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

Также в эту таблицу вставляются записи для последней вставленной информации о партии. то есть, когда вставлено 5 кортежей в таблицу AB C и, допустим, что последний идентификатор элемента в пакете - X, тогда запись в таблице (центральное хранилище ключей) также вставляется как ('AB C' , X).

Имеет ли значение эта архитектура?

А также где я могу найти тематическое исследование распространенной крупномасштабной системы ERP, построенной на заказ?

Answer 1

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

Кирпичная стена №1: UUID удобны, потому что клиенты могут создавать их, не запрашивая значения у какого-то центрального сервера. Но UUID очень случайны. Это означает, что в большинстве ситуаций каждая ссылка вызывает попадание на диск, потому что идентификатор вряд ли будет кэширован.

Кирпичная стена # 2: попросите центральный сервер, у которого есть AUTO_INCREMENT под крышкой, разрешить из идентификаторов. Я смотрел сайт в социальной сети, который из-за этого ничего не делал, кроме сбора изображений для обмена cra sh. И это несмотря на то, что существует сервер, единственная цель которого - раздавать числа.

Решение №1:

Вот одно (из нескольких) решений, которое позволяет избежать большинства проблем: иметь центральный сервер, который раздает 100 идентификаторов за раз. После того, как клиент израсходовал предоставленные 100, он запрашивает новую партию. В случае сбоя клиента некоторые из последних 100 «теряются». Ну что ж; ничего страшного.

Это решение в 100 раз лучше кирпичной стены №2. И идентификаторы гораздо менее случайны, чем идентификаторы кирпичной стены №1.

Решение №2: Каждый клиент может генерировать свои собственные 64-битные полупоследовательные идентификаторы. Номер включает номер версии, некоторые часы, часть дедупликации и идентификатор клиента. Так что это примерно в хронологическом порядке (по всему миру) и гарантированно будет уникальным. Но все же есть хорошая локальность ссылок для элементов, созданных примерно в то же время.

Примечание: мои методы могут быть адаптированы для использования в отдельных таблицах или в качестве убер-числа для всех таблиц. Это различие могло быть вашим «настоящим» вопросом. (Другие ответы касаются этого.)

Answer 2

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

Вот некоторые «преимущества»:

1. Любой идентификатор ресурса, обнаруженный в любом месте системы, можно легко идентифицировать, независимо от типа.
2. Если в таблице есть какой-либо текст (например, имя или описание), то все это централизовано, что облегчает многоязычную поддержку.
3. Ссылки на внешние ключи могут работать с несколькими типами.

Третий вариант не является преимуществом, потому что он имеет обратную сторону: невозможность указать конкретный c тип для ссылок внешнего ключа.

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

Answer 3

Если я правильно понимаю, вы спрашиваете, зачем кому-то заменять идентификаторы, уникальные только для таблицы

• ТАБЛИЦА клиентов (id_client AUTO_INCREMENT, имя, адрес)
• ТАБЛИЦА продукты (id_product AUTO_INCREMENT, имя, цена)
• ТАБЛИЦА заказы (id_order AUTO_INCREMENT, id_client, date)
• ТАБЛИЦА order_details (id_order_detail AUTO_INCREMENT, id_order, 10 id_product, amount11 * 10 *

  с глобальными идентификаторами, уникальными для всей базы данных

  • объекты ТАБЛИЦА (id AUTO_INCREMENT)
  • ТАБЛИЦА клиенты (id_object, имя, адрес)
  • ТАБЛИЦА продукты (id_object, name, price)
  • ТАБЛИЦА заказов (id_object, id_object_client, date)
  • ТАБЛИЦА order_details (id_object, id_object_order, id_object_product, amount)

  (Из Конечно, вы все равно можете называть эти идентификаторы id_product et c., а не id_object. Я использовал имя id_object только для пояснения.)

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

  Второй подход, следовательно, приводит к тому, что сеансы ждут своей очереди каждый раз, когда они хотят вставить данные, независимо от того, в какую таблицу, поскольку все они получают свои ID из таблицы объектов. Большим преимуществом является то, что при экспорте данных у вас есть глобальные ссылки. Допустим, вы экспортируете заказы, а получатель сообщает вам: «У нас проблемы с данными вашего заказа 12345. Что-то не так с вашими данными». Было бы здорово, если бы вы могли сказать им: «12345 - это не идентификатор детали заказа, а идентификатор продукта. У вас есть проблемы с импортом продукта или вы можете сообщить мне идентификатор детали заказа, о котором идет речь?» вместо того, чтобы часами смотреть на подробный отчет о заказе, который имеет номер 12345, хотя на самом деле это не имеет никакого отношения к проблеме?

  Тем не менее, может быть лучше использовать первый подход и добавьте UUID во все таблицы, которые вы будете использовать для внешней связи. Никакой борьбы за следующий ID и никаких ошибочных ID при общении: -)

Answer 4

Это обычная стратегия, используемая в хранилище данных для отслеживания номера пакета после успешной или неудачной загрузки данных, в случае, если загрузка данных не удалась, вы скажете что-то вроде 'AB C', 'Batch_num' и ' Error_Code 'в таблице управления пакетами, так что ваш дальнейший logi c загрузки может решить, что делать с ошибкой, и может легко отслеживать загрузку, в случае, если вы хотите перепроверить, мы можем архивировать данные. Этот идентификатор обычно генерируется последовательностью в базе данных, одним словом, он в основном используется для мониторинга целей.

Вы можете обратиться к этой ссылке для получения более подробной информации